mirror of https://github.com/dreamhunter2333/cloudflare_temp_email.git synced 2026-05-11 09:59:46 +08:00

Files

jiaxin ebeb94ed23 fix: auto initialize default send balance (#985 )

* fix: auto initialize default send balance

* fix: tighten send access auto init flow

* refactor: centralize send balance state

* fix: separate legacy repair from admin control in send balance

Add an `address_sender.source` column to distinguish legacy / auto /
user / admin rows. `ensureDefaultSendBalance` now only repairs rows
with `source IS NULL`, so admin-disabled and user-requested rows are
never overwritten. Admin POST writes tag `source = 'admin'`; new
auto-init inserts tag `'auto'`; `requestSendMailAccess` inserts tag
`'user'`.

Bumps DB_VERSION to v0.0.8 with the usual `PRAGMA table_info` guarded
ALTER, plus a standalone SQL patch under db/.

Adds E2E regressions: legacy repair path, admin-disabled rows stay
disabled across settings and send, send after admin deletion
auto-initializes a fresh row.

* fix: drop runtime legacy repair; backfill source='legacy' on migrate

Pre-v0.0.8 schema cannot distinguish legacy request-send-access
remnants from admin-disabled rows — both share `balance = 0,
enabled = 0`. Letting ensureDefaultSendBalance repair that shape on
upgrade could silently re-enable an admin-disabled row.

Remove the runtime repair path entirely:

- `ensureDefaultSendBalance` now uses `ON CONFLICT(address) DO NOTHING`;
  existing rows are never touched.
- The v0.0.8 migration (and the matching SQL patch) backfills every
  pre-existing row with `source = 'legacy'`, making pre-migration
  state explicitly off-limits to runtime auto-init.
- E2E: flip the legacy test to the negative direction — a
  `source='legacy'` zero-balance row stays untouched by settings
  reads and send attempts. Harden `resetSenderToLegacy` to return
  404 when `meta.changes < 1`.
- Update changelog and docs: legacy/admin-disabled rows must be
  restored manually via the admin UI.

* refactor: collapse send balance auto-init to missing-row insert

Per review feedback: the runtime guarantee we actually need is
"create an address_sender row when one is missing, leave existing
rows alone". Once `ensureDefaultSendBalance` switched to
`ON CONFLICT DO NOTHING`, the `source` column, the v0.0.8 migration,
and the `resetSenderToLegacy` test endpoint became dead weight —
the DO NOTHING path already protects admin-disabled and admin-edited
rows without any provenance metadata.

- Drop `address_sender.source` and the v0.0.8 migration; revert
  DB_VERSION to v0.0.7. No schema change ships with this PR.
- Strip the `source` field from `ensureDefaultSendBalance`,
  `requestSendMailAccess`, and the admin-update path.
- Remove the `/admin/test/reset_sender_to_legacy` test endpoint and
  its E2E helper; the negative legacy-repair test it served is no
  longer needed because the runtime no longer touches existing rows.
- E2E coverage stays focused on the three guardrails: missing-row
  auto-init, admin-disabled rows stay disabled, admin deletion
  triggers a fresh re-insert.
- Tighten changelog and docs to "auto-initialize missing rows".

* docs: align common-issues with missing-row-only auto-init

The FAQ entries for "DEFAULT_SEND_BALANCE set but still No balance"
still described the old behaviour of repairing legacy
`balance = 0 && enabled = 0` rows. Rewrite both zh and en rows to
match the current runtime: only addresses with no existing
`address_sender` row get auto-initialised; legacy, admin-disabled,
and admin-edited rows must be restored manually through the admin
console.

2026-04-20 12:40:14 +08:00

6.5 KiB

Raw Blame History

FAQ

[!NOTE] Note If you don't find a solution here, please search or ask in Github Issues, or ask in the Telegram group.

General

Issue	Solution
Sending emails to authenticated forwarding addresses using Cloudflare Workers	Use CF's API for sending, only supports recipient addresses bound to CF, i.e., CF EMAIL forwarding destination addresses
Binding multiple domains	Each domain needs to configure email forwarding to worker
Subdomain cannot receive email	Subdomains must have Email Routing enabled separately on Cloudflare with their own DNS records and Catch-all rule. Enabling it only on the apex domain does NOT cover subdomains. See Email Routing

Issue	Solution
`Uncaught Error: No such module "path". imported from "worker.js"`	Reference
`No such module "node:stream". imported from "worker.js"`	Reference
`Subdomain cannot send emails`	Reference
`Failed to send verify code: No balance`	Set unlimited emails in admin console or increase quota on the sending permission page
`Github OAuth unable to get email 400 Failed to get user email`	GitHub user needs to set email to public
`Cannot read properties of undefined (reading 'map')` during page initialization	First check whether `/open_api/settings` is returning valid data. In a direct Worker deployment, this usually means Worker variables were not configured correctly, so verify JSON-format variables such as `DOMAINS` and `ADMIN_PASSWORDS`. If this happens in a Pages deployment because requests are going to the wrong backend address, continue with the Pages troubleshooting section below

Issue	Solution
`network error`	Use incognito mode or clear browser cache and DNS cache
Pages deployment shows the `map` error, or API requests such as `/admin/users` / `/admin/new_address` return `405 Method Not Allowed`	This is usually caused by an incorrect frontend backend address. Check `VITE_API_BASE`, the URL entered when generating the zip in the UI guide, or `FRONTEND_ENV`: for separate frontend/backend deployment talking directly to Worker, it should be the backend Worker API root URL, start with `https://`, and have no trailing `/`; if you use `PAGE_TOML` to proxy backend requests through Page Functions, `VITE_API_BASE` can be left empty to use same-origin requests. See Pages Frontend Deployment
Refreshing page or directly visiting `/admin`, `/user` returns 404	This project is a Single-Page Application (SPA). When deploying Pages via UI, set "Not Found handling" to `Single-page application (SPA)` in the advanced options. See Pages Frontend Deployment

Issue	Solution
Set `DEFAULT_SEND_BALANCE` but still getting `No balance`	Refresh the settings page or try sending again first. When `DEFAULT_SEND_BALANCE > 0`, the system only auto-initializes the default quota for addresses that have no `address_sender` row yet; existing rows — including legacy `balance = 0 && enabled = 0` rows, admin-disabled rows, and admin-edited rows — are never modified by the runtime and must be manually restored by an admin (enable + set balance). Alternatively, add the address to the "No Limit Send Address List" in the admin console, or configure `NO_LIMIT_SEND_ROLE`
Error: `Please enable resend or smtp for this domain`	You need to configure `RESEND_TOKEN` or `SMTP_CONFIG` first. See Configure Email Sending
`SMTP_CONFIG` configured but sending fails	Make sure the JSON key is your own sending domain (e.g. `your-domain.com`), not the example `awsl.uk`. See Configure Email Sending

Issue	Solution
Set `ENABLE_ADDRESS_PASSWORD` but Foxmail/Outlook cannot login	`ENABLE_ADDRESS_PASSWORD` only enables the "address password login" web API. It does NOT provide standard IMAP/SMTP service. To use mail clients, you need to deploy the SMTP/IMAP Proxy Service

Telegram Bot

Issue	Solution
`Telgram Bot failed to get email: 400: Bad Request:BUTTON_URL_INVALID`	tg mini app URL is incorrect, should be the pages URL
`Telegram bot bind error: bind adress count reach the limit`	Need to set worker variable `TG_MAX_ADDRESS`

Github Actions

Issue	Solution
After Github Action deployment, CF always shows preview branch	Go to CF pages settings to confirm that the frontend branch matches the Github Action frontend deployment branch

6.5 KiB Raw Blame History

FAQ

General

Worker Related

Pages Related

Email Sending Related

Mail Client Related

Telegram Bot

Github Actions

6.5 KiB

Raw Blame History