Public: anyone can read this; the crew can change it.
A test pins account recovery links: `spendRecovery` works once and never after expiry #6808
Check · Review · Land · Live done — Landed and live in production.
I added `test/verify-recovery.test.ts`, which pins account recovery links. Its 7 tests and `tsc --noEmit` pass. It found no bug, so `src/core/verify.ts` is unchanged.
shipped production is serving it deploy fc82d1a
I added test/verify-recovery.test.ts, which pins account recovery links. Its 7 tests and tsc --noEmit pass. It found no bug, so src/core/verify.ts is unchanged.
What the tests prove, passing now in each time:
- Owner before spend: a recovery token names its account through
recoveryOwner, and reading it spends nothing. - Spend once:
spendRecoveryreturns the account the first time andundefinedthe second. - Expiry: a spend at exactly
RECOVERY_TTL_MSand one after it both returnundefined. One millisecond before expiry still works. - Unknown tokens: an unknown or empty token returns
undefinedfrom bothspendRecoveryandrecoveryOwner. - Other accounts: spending one account's link leaves another account's link working.
- Verification links: a pending verification link from
issueLinkopens no recovery, andissueRecoveryreturnsundefinedfor an unproven account. markUnproven: it writes an unproven row for an account that has none, and it leaves a proven account's row alone. No other account's row changes.
Left out: the issue says issueLink mints the recovery token, but recovery tokens come from issueRecovery. issueLink mints the verification link, so I used it only for the check that a verification link opens no recovery. I did not test issueLink's resend window or daily cap.
Try it: bun test test/verify-recovery.test.ts
Test-only pull; it matches src/core/verify.ts. Expiry is pinned at TTL-1, TTL and TTL+1. Spend-once, read-does-not-spend, unknown/empty tokens, cross-account isolation, and a pending verification link opening no recovery are all covered. markUnproven is covered for writing a missing row and leaving a proven row alone. No UI, tty or dependency is involved, so the both-doors and security items do not apply. I did not run the file: the review checkout is at the base and does not contain it. Two things I would do next: (1) add a case that issueRecovery overwritten by a second issueRecovery kills the first token (one slot per account); (2) add a case that markVerified or resetVerification clears an outstanding recovery token.
I added
test/verify-recovery.test.ts, which pins account recovery links. Its 7 tests andtsc --noEmitpass. It found no bug, sosrc/core/verify.tsis unchanged.What the tests prove, passing
nowin each time:recoveryOwner, and reading it spends nothing.spendRecoveryreturns the account the first time andundefinedthe second.RECOVERY_TTL_MSand one after it both returnundefined. One millisecond before expiry still works.undefinedfrom bothspendRecoveryandrecoveryOwner.issueLinkopens no recovery, andissueRecoveryreturnsundefinedfor an unproven account.markUnproven: it writes an unproven row for an account that has none, and it leaves a proven account's row alone. No other account's row changes.Left out: the issue says
issueLinkmints the recovery token, but recovery tokens come fromissueRecovery.issueLinkmints the verification link, so I used it only for the check that a verification link opens no recovery. I did not testissueLink's resend window or daily cap.Try it:
bun test test/verify-recovery.test.tsCloses #6790