Retire access tokens leaked before the server:clients fix (GRYT-1259)

[sivert-io]

Review-required path

This adds a migration under packages/server/src/db/** (persistence), so it needs a read of the whole diff before it merges. The changed files are the new tokenReissueMigration.ts, its test, and one call plus one import wired into connection.ts.

Why

server#194 (GRYT-1239) stops server:clients and server:details.clients from leaking every member's live access token, but it cannot recall a token that already leaked. While the bug was live an attacker could roll a captured access token forward indefinitely by refreshing inside each fifteen-minute window, so an upgrade that only stops new leaks still leaves the captured ones working.

What it does

reissueAccessTokensAfterLeak bumps server_config.token_version by one, once, inside runMigrations. That counter is what requireAuth, session restore and token:refresh compare a token against, so every access token minted before the bump is refused from then on.

• Fires once. A schema_meta marker (access_token_reissue_gryt1239) records that it ran, in the same transaction as the bump, so a later boot never repeats it.
• Skips a fresh install. It only bumps a database that already has member rows. A server nobody ever joined never issued a token to leak, so there is nothing to retire; the marker is still written so it never reconsiders.
• Refresh tokens keep working. The bump touches only server_config. A live client whose access token is now refused falls back to its refresh token and re-mints at the new version on its own, so the sign-out is a brief reconnect rather than a re-login. Refresh tokens were never exposed by the leak.
• One log line names the new counter value when it fires.

Tests

tokenReissueMigration.test.ts:

• bumps the counter once on a server that had members;
• does nothing on the second boot;
• spares a fresh install that never had a member;
• an old access token is refused at requireAuth and at token:refresh afterwards;
• a refresh token still mints a new access token, and that new token is accepted where the old one was refused.

Verified end to end on a throwaway server: joined on origin/main (the code before this migration), captured the access and refresh tokens, then restarted onto this branch against the same data directory. The migration bumped token_version 0 to 1 and logged one line; the captured access token came back token:revoked (token_version_mismatch) and got no session; the refresh token minted a fresh access token; the fresh token restored the session. A second restart did not bump again.

Local CI: yarn test (1336), yarn test:examples (9), npx tsc --noEmit, yarn build, npx eslint ., node scripts/check-comment-length.mjs, all clean.

Release

This is the recall half of the server:clients fix. It should ship together with server#194 (GRYT-1239), and with #192 (GRYT-1238) and #193 already on main.

🤖 Generated with Claude Code