Problem
-------
1. Re-clicking an already-confirmed confirmation link (e.g. /confirm?token=…)
returned from confirmSubscription because the SQL WHERE
clause required . The caller then threw an
ActionError('invalid or expired') which rendered the 'Email not confirmed'
error page — misleading for someone who had already confirmed.
2. A second PUT /subscription/email with the same email+frequency could
silently bypass the upsert path when getSubscriptionByPubkey found the
active row but updateSubscription returned it unchanged (email and
frequency matched). While the unique index prevented a true duplicate
INSERT, the code path was fragile and the regression test was missing.
Changes
-------
database.ts:
- confirmSubscription now returns { sub, alreadyConfirmed } | undefined.
First it tries the existing UPDATE (unconfirmed tokens only). If that
returns no rows, it looks up the key directly: if the row exists and is
already confirmed, returns { sub, alreadyConfirmed: true }. If the row
doesn't exist or is unsubscribed, returns undefined (invalid/expired).
- Exported new ConfirmResult type for callers.
actions.ts:
- confirmSubscriptionAction destructures the new return type.
- Only registers the cron job on fresh confirmation (not re-confirms).
- Returns the ConfirmResult so the route can distinguish the two cases.
server.ts:
- /confirm route checks result.alreadyConfirmed and renders
confirm-already.html instead of confirm-success.html.
pages/confirm-already.html:
- New page with title 'Email already confirmed' and an info message
explaining the address was already confirmed.
Tests:
- test/confirm-already-confirmed.test.ts — NEW (3 tests): first confirm
succeeds with alreadyConfirmed=false; second confirm returns
alreadyConfirmed=true; nonexistent token returns undefined.
- test/duplicate-subscription.test.ts — NEW (4 tests): full cycle of
register → confirm → re-register → assert one active row with
unchanged key, verifying the upsert is idempotent.
- Adapted 3 existing test files to destructure the new ConfirmResult.
When a confirmed subscriber calls PUT /subscription/email with a changed
frequency, db.updateSubscription updates the row but the running CronJob
captured the original frequency in createJob and was never rescheduled.
A subscriber switching daily→weekly kept the daily cadence until restart.
Fix: in actions.ts:registerSubscription, call worker.registerSubscription(sub)
when the subscription is already confirmed, so addJob stops the old job and
creates a new one with the updated frequency.
Changes:
- src/actions.ts: add else branch calling worker.registerSubscription when
sub.confirmed_at is set
- test/reschedule-on-frequency-change.test.js: new failing-before/passing-after
test verifying the cron expression is updated after frequency change
Closes mailship-e04
Switch the subscribe endpoint from POST to an idempotent PUT so clients can
always upsert without a stateful lookup first.
- Add GET /subscription/email?pubkey= lookup so clients can avoid re-POSTing.
- insertSubscription no longer clears confirmed_at unless the email address
changes; a frequency change keeps the existing confirmation.
- registerSubscription only sends a confirmation email when the subscription
is new, unconfirmed, or the email address changed.
- Update integration test and README for the PUT endpoint.
