test(browser): wait for the app's own quota cooldown before retrying

[loganj]

🤖

Summary

• Fixes an intermittent browser-test failure. After a rate-limit ("quota") refusal, the test clicked Retry live updates at the time the cooldown should have ended, but the button sometimes stayed on screen.
• Cause: the test measured the cooldown on the test machine's real clock, starting when the fake relay refused. The app starts its own cooldown later, when the browser processes the refusal. That happens after the broker hop and whenever the busy renderer gets to it. If the test's single recovery click arrived first, the app ignored it, and the test failed.
• Now the two live retry tests use Playwright's page clock. After the error appears and the ignored clicks are checked, the test advances the browser clock by the full advertised delay. The app sets its deadline before it shows the error, so this always passes that deadline, however late the browser processed the refusal.

Details

• The broker (the local server between the app and the relay) also pauses its own request queue for the advertised delay, on the real clock. It sets that pause before it finishes sending the refusal. The fixture records the finish time, and the tests wait until exactly that time plus the delay, with no extra margin. This keeps the broker from refusing the retry.
• The older-page retry in history-loading.spec.mjs has no cooldown in the browser. Only the broker holds it, so that test waits for the broker bound only.
• The existing before- and after-retry request-count, route, and reading-position assertions are unchanged. No test cases or engines are removed. No product code changes.

Evidence

All local runs are on Chromium unless noted, using playwright test --config tests/browser/playwright.config.mjs --no-deps on the quota retry tests in live.spec.mjs and history-loading.spec.mjs (--repeat-each 3).

Injected delay (test-only patch)	main	Server timestamp + 250 ms (first version of this PR)	This PR
400 ms between relay refusal and broker response	6 of 9 fail	9 of 9 pass	9 of 9 pass
400 ms between browser fetch receiving the 429 and the app reading it	—	3 of 9 fail (live.spec.mjs:32, Retry button still visible)	9 of 9 pass

• Without injection, both full files pass 40 of 40 on Chromium and 40 of 40 on WebKit (--repeat-each 5).
• Timing, Chromium, one worker, three runs each, compared with the first version of this PR: live.spec.mjs:32 8.7–8.9 s → 7.8–7.9 s, the roster retry 6.3–6.5 s → 5.4–6.4 s, and the older-page retry 5.5–5.6 s → 4.4–4.6 s. The page clock replaces up to 3 s of real waiting.
• Not checked: the browser-side delay injection was not run on WebKit.

[wesbillman]

Star Lord’s automated source review via Wes’s account — non-blocking COMMENT, not approval or merge authorization.

Reviewed head 28665d6ec98f4b79b082ce1b5b642c64d6c3fd3b against base/merge-base 4012979b1d200c3793714d7d7438e6dcd5231668.

One actionable finding (P2), inline: the new cooldown predicate still uses a server-side timestamp plus a scheduling margin rather than the browser-owned retry boundary. Moving the timestamp past broker work improves the reported upstream-delay case, but does not remove the remaining race.

The four-file change retains the existing recovery, request-count, healthy-route and reading-position assertions; no browser cases or engines are removed. I traced the three callers, fixture response lifecycle, quota normalization, and session/store retry ownership. No additional actionable findings in that scope.

Validation/evidence: source-only; I did not run PR code, tests, builds or the app. One read-only CI snapshot shows all automatic lanes successful in run 36180219561. Its reports identify merge snapshot b6ffa8c872003133abe8a4152df2a340e4ad4faf (this head/base), Ubuntu, Playwright 1.63.0, two workers and zero retries. Both affected files passed in Chromium/WebKit shard 2: each shard reports 98/98 passing; wrapper elapsed time 271.73s/374.42s and summed test execution 521.53s/724.44s respectively. Slowest file in each was navigation-sidebar.spec.mjs (72.74s/98.52s). These are current-run observations, not a matched before/after cost comparison or proof against the remaining ordering. The PR’s injected-delay/repeat results and estimated added wait were not independently reproduced. Native/manual acceptance and a controlled browser-consumption-delay check remain unverified.

[wesbillman]

Star Lord automated source follow-up

Published through Wes’s GitHub account (wesbillman); this is a non-blocking COMMENT, not Wes’s manual approval or merge authorization.

The prior P2 cooldown-ordering finding is addressed; no new actionable source defects found in this follow-up.

Reviewed head 9492d3b1d45651a0a9e9c6e5fdd8df65c7fa2678 against base/merge-base 734949a62229c56b2e3368701a4b4d5413ac555a, following review of 28665d6ec98f4b79b082ce1b5b642c64d6c3fd3b.

• tests/browser/live.spec.mjs:22–32, 95–106, 174–202: the browser clock is installed before navigation, and the full advertised delay is advanced after the visible quota error and ignored retry clicks. The actual catch-up and roster owners set their performance.now() deadlines before publishing that error (session.ts:1783–1804, store.ts:881–919). This removes the old assumption that server response finish plus 250 ms bounds browser consumption.
• fixture.mjs:1382–1391 and policy-relay.mjs:104–112: response finish remains a conservative bound for the separate real-time broker pause. admittedApiRequest sets that pause before returning the refusal; the older-page retry has no additional browser cooldown and uses this broker-only bound.
• The four-file change is test-only (35 additions, 10 deletions). No browser cases or engines are added/removed; the eight cases across the affected spec files remain, including request-count, healthy-route, recovery and reading-position assertions.

Validation limits: source analysis only; no tests, builds or app workflows were executed. Pinned source extracts were verified against Git blobs and the diff whitespace check passed. The PR reports delayed-consumption controls and repeated Chromium/WebKit file passes, but I did not reproduce those results or establish their exact checked snapshots. The one current-head CI snapshot showed the JavaScript, Rust and browser jobs still running; DCO and security checks had passed. Completed job-summary counts, wall/summed execution times and slowest-file evidence were therefore unavailable at that snapshot; no independently verified performance comparison or final CI/human acceptance is claimed. The author explicitly leaves the browser-consumption-delay injection on WebKit untested. No CI polling was performed.