[freeqaz]

Problem

postgres-prepared-token-service.test.ts "rejected fresh GitHub material recovers once across separate owners without replay" failed on main (PostgreSQL Platform, run 39972061000) at

assert.deepEqual(results.sort(), ["committed", "idle"])   // got ["committed", "retired"]

Two owners run one maintenance pass at once over a family whose current token was just rejected. A pass is discover, then retire, then prepare, and it reports prepare's result, or the retire step's result when prepare claimed nothing. The winner claims, issues the replacement and commits it, and that commit moves the rejected token into retirement custody. The loser claims nothing, so it reports its own retire step:

• idle when its retire step ran before the winner's commit (the next pass then retires the rejected token);
• retired when its retire step ran after that commit and revoked the rejected token.

Both are correct; retirement is shared by every owner and is never replayed. The test only accepted idle. Delaying the loser by about 30 ms or more is enough to produce retired, so a slow runner hits it. The failing test took 510 ms; nothing hung. Since the test landed (#2487), this is 1 failure in about 230 completed PostgreSQL Platform jobs.

This is not a product bug: the loser never claims the family, never issues, and the token it retires is the superseded, rejected one.

Change

Test only.

• New shared helper raceMaintenance(owners, signal) in tests/helpers/github-metadata-exchange.mjs: runs one pass on each owner at once, asserts exactly one commits, and returns the sorted losing results. Both prepared GitHub race tests use it.
• postgres-prepared-github-lifecycle.test.mjs (cold family, nothing to retire) still requires the loser to be idle.
• postgres-prepared-token-service.test.ts accepts idle or retired for the loser and checks retirement directly, by counting the provider revocations of the rejected token: one before the race (the test's own), a second right after the race only if the loser reported retired, exactly two after the next ready pass, and still two at the end. The new final count also catches a retirement replay that the old test missed. Before the test revokes the replacement itself, it checks that no maintenance pass revoked it.

Verification

• Forced race (loser delayed by a random 0-300 ms): the old test failed 9 of 10 runs with the CI message; the new test passed 16 of 16 on fresh databases, with both idle and retired losers.
• Mutant: leaving a retired token in retirement custody (so later passes revoke it again) passes the old test 3/3 and fails the new one 3/3.
• Pins at 2 CPUs, each run on a fresh database: 90/90 as three parallel loops on the first head, 30/30 with CPU stress on the same cores, and 90/90 as three parallel loops on the final head. The lifecycle test passes 3/3.
• tsc --build --force, eslint and prettier are clean on the touched files.

Risks

Low, test only. The race test is a bit more lenient about the losing result, but the invariants it protects are now asserted directly: exactly one commit, one new issue, and exactly one retirement of the rejected token with no replay.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.