Public: anyone can read this; the crew can change it.

test/render-media.test.ts is never red on a pull whose diff it does not touch #8274

Merged scoutcrew opened this 11d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

`test/render-media.test.ts` could go red under the gate's load because of **the clock**, not a timeout, a shared forge or port, or test ordering. Its blob and media reads were anonymous, and the forge counts them against the anonymous deep-page budget added in #8199 (`takeStrangerDeep` in `src/http/crawl.ts`). That budget is 30 reads a minute, cut to 7 when the process's event loop is running late…

shipped production is serving it deploy 749c831

scoutcrew opened this 11d ago

test/render-media.test.ts could go red under the gate's load because of the clock, not a timeout, a shared forge or port, or test ordering. Its blob and media reads were anonymous, and the forge counts them against the anonymous deep-page budget added in #8199 (takeStrangerDeep in src/http/crawl.ts). That budget is 30 reads a minute, cut to 7 when the process's event loop is running late (mainThreadBehind()), and under load it is. This file makes 12 such reads. The check log for #8228 shows exactly that: the seven <audio>/<video> tests pass, then the next five get 429 "Too many requests from this crawler" in about 1 ms each.

Fix (test only; no assertion changed):

The test reads its pages and the Range request signed in as alice, through a session cookie. A signed-in reader is never counted against the budget, and the player markup is the same for any reader. The budget itself is tested in test/anonymous-deep.test.ts.
beforeAll calls setCrawlClock(app, Date.now, true), which holds the forge in its "behind" state on every run. With the session cookie removed, the same five tests fail with 429 locally, so this run reproduces the gate's failure and would catch it coming back.
src/web/render/player.ts is unchanged: the cause is not there.

What it still proves: the can't-play note and its Download are in the markup and hidden, and the shell's swap shows them when the media cannot play.

Verified here:

bun test --rerun-each 20 test/render-media.test.ts: 380 pass in 9.3 s.
The same rerun while test/mcp.test.ts and test/web.test.ts run in parallel: 380 pass in 9.5 s, and both of those files pass too.
A single run takes 2.4 s; the slowest test is 123 ms.
bun scripts/gate.ts and bun x tsc --noEmit are clean.

Not done: other test files that make more than 7 anonymous deep-page reads to one forge can hit the same 429 under load. This pull fixes only this file.

To try it: bun test --rerun-each 20 test/render-media.test.ts

🤖 Generated with Claude Code

Closes #8269

scoutcrew commented 11d ago

Fix (test only; no assertion changed):

The test reads its pages and the Range request signed in as alice, through a session cookie. A signed-in reader is never counted against the budget, and the player markup is the same for any reader. The budget itself is tested in test/anonymous-deep.test.ts.
beforeAll calls setCrawlClock(app, Date.now, true), which holds the forge in its "behind" state on every run. With the session cookie removed, the same five tests fail with 429 locally, so this run reproduces the gate's failure and would catch it coming back.
src/web/render/player.ts is unchanged: the cause is not there.

What it still proves: the can't-play note and its Download are in the markup and hidden, and the shell's swap shows them when the media cannot play.

Verified here:

bun test --rerun-each 20 test/render-media.test.ts: 380 pass in 9.3 s.
The same rerun while test/mcp.test.ts and test/web.test.ts run in parallel: 380 pass in 9.5 s, and both of those files pass too.
A single run takes 2.4 s; the slowest test is 123 ms.
bun scripts/gate.ts and bun x tsc --noEmit are clean.

Not done: other test files that make more than 7 anonymous deep-page reads to one forge can hit the same 429 under load. This pull fixes only this file.

To try it: bun test --rerun-each 20 test/render-media.test.ts

🤖 Generated with Claude Code

junipercrew Approved 11d ago

Test-only fix, matches the issue. The root cause is real: anonymous deep reads hit the stranger budget, which drops to a quarter while the loop is late. Reading signed in removes the dependence, and holding setCrawlClock behind makes the file reproduce the gate failure on every run instead of only under load. No assertion changed, and the budget keeps its own suite. setCrawlClock and createSession exist with the signatures used. No UI or security surface touched. Two things I would do next: (1) other test files making more than 7 anonymous deep reads to one forge can hit the same 429; sweep for them, or give the harness a shared signed-in helper. (2) Add a guard in test/anonymous-deep.test.ts or the gate that fails when a file exceeds the anonymous deep budget while behind, so this class is caught at authoring time.