[SID:4778] A late refresh after a switch is 'superseded', not 'revoked'; an unconfirmed refresh no longer clears the cookies (AC2b · AC2c) (#5236) * [SID:4778] backend test: a refresh that leaves with the old token after a switch is refused (real PG) Pins the server half of the switch x refresh overlap: a switch kills the session's old refresh token at once (no 180 s window), so a refresh that left with it answers 401; the other order leaves two live tokens. Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] WIP PR B: a token a switch ended is answered TOKEN_SUPERSEDED inside a short window (server half) Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] WIP PR B: BFF refresh route · proxy · client — superseded and unconfirmed answers do not clear the cookies; one more ask after superseded Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] PR B: tests for successor owner and proxy outcome precedence; refresh route non-401 check simplified Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] PR B review fixes: unreadable 401 body is dead, a switch renewal that is only unconfirmed does not end the session, a 200 needs both tokens, race test asserts the word Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] superseded: follow the successor chain to a live token (a rotated hop whose grace window was closed by an end is not alive) Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] superseded: a recent revoked hop with no link yet is a rotation in flight (alive); proxy refresh takes only string tokens Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] tests: a malformed 200 with a valid access token is not written as cookies (proxy) Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] switch-account links its rotation to the new token (a rotated hop must not look like a rotation in flight for ever) Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] close the superseded chain walk: a switch-ended hop no longer stops it, and a long walk answers superseded A late refresh with the original token after TWO switches inside the window (or switch, rotation, switch) used to answer TOKEN_REVOKED, because the walk stopped at a hop whose expires_at was closed. A switch-ended hop closes expires_at AND carries replaced_by (a logout-ended one carries none), so the walk now stops only for an end that moved nowhere (or a live token that simply expired). The 5-hop cap is now 64 and a walk that runs out of hops answers TOKEN_SUPERSEDED (one more ask by the client; a dead session is then answered REVOKED), never a forced logout. Tests (real PG): second switch inside the window, switch-rotation-switch, 5/6/8 rotations after a switch, a walk over the cap, an expired live successor stays REVOKED; logout branches stay REVOKED. Co-Authored-By: Claude Sonnet 5.5 * [SID:4778] pin the walk cap to exactly 64 hops; say the cap limit and what the expired-live-token cell catches A real-PG cell for the intended cap (switch, 63 or 64 refreshes, the newest token logged out: 63 → REVOKED, 64 → SUPERSEDED), so a cap of 5, 63 or 65 turns it red. The comments now state the limit of the exhausted walk (a logged-out session beyond the cap gets one SUPERSEDED, the next request gets the real REVOKED and clears the cookies) and that the expired-live-successor cell only catches deleting both «expired end» conditions. Co-Authored-By: Claude Sonnet 5.5 --------- Co-authored-by: Claude Code Co-authored-by: Claude Sonnet 5.5

Sunbelt Computer Software

PL/B Language Development and Support