Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:38g10d7hu5 was degraded 49 minutes today: trevato/forge: "the walked repository pages exist" failed on 3 pulls in the last hour — the lane's red, not theirs; the… #8290

I think I found the cause of the red "the walked repository pages exist" check and fixed the test. I couldn't reproduce the failure, so the diagnosis is inferred from the code.

The test passes here, as it did before the change. Tools run: bun x tsc --noEmit and bun scripts/gate.ts showed no errors, and test/forge-webspec.test.ts passes (5 of 5). I didn't run the rest of the suite, since the forge runs the full check on the push.

Cause: the forge refuses strangers who read repository pages too fast (#8199, src/http/crawl.ts). The limit is 30 deep pages a minute per address, and it divides by 4 while the event loop is running late. That leaves about 7 on a loaded check machine. The webspec tests in test/forge-webspec.test.ts read dozens of such pages from one address (they have no peer). On a loaded machine they ran past the budget and the later reads got 429 instead of 200. That would hit this test, which runs after the earlier walks.

Change: test/forge-webspec.test.ts now gives each request its own one-minute crawl window, using setCrawlClock. These tests walk pages and don't measure the budget, so their result no longer depends on load. No production code changed. The crawl-budget tests still cover the limit itself.

Not done: I didn't change the budget or the lag divisor, because that is a production policy decision.

To try it: run bun test test/forge-webspec.test.ts. After it merges, the sentinel's shared:01m23vygyffx5hg2f5vm8r74sr:38g10d7hu5 should stay out of the degraded list for a day.

🤖 Generated with Claude Code

Closes #8280

I think I found the cause of the red "the walked repository pages exist" check and fixed the test. I couldn't reproduce the failure, so the diagnosis is inferred from the code.

The test passes here, as it did before the change. Tools run: bun x tsc --noEmit and bun scripts/gate.ts showed no errors, and test/forge-webspec.test.ts passes (5 of 5). I didn't run the rest of the suite, since the forge runs the full check on the push.

Cause: the forge refuses strangers who read repository pages too fast (#8199, src/http/crawl.ts). The limit is 30 deep pages a minute per address, and it divides by 4 while the event loop is running late. That leaves about 7 on a loaded check machine. The webspec tests in test/forge-webspec.test.ts read dozens of such pages from one address (they have no peer). On a loaded machine they ran past the budget and the later reads got 429 instead of 200. That would hit this test, which runs after the earlier walks.

Change: test/forge-webspec.test.ts now gives each request its own one-minute crawl window, using setCrawlClock. These tests walk pages and don't measure the budget, so their result no longer depends on load. No production code changed. The crawl-budget tests still cover the limit itself.

Not done: I didn't change the budget or the lag divisor, because that is a production policy decision.

To try it: run bun test test/forge-webspec.test.ts. After it merges, the sentinel's shared:01m23vygyffx5hg2f5vm8r74sr:38g10d7hu5 should stay out of the degraded list for a day.

🤖 Generated with Claude Code

I merged main into the branch and pushed. The check failure came from main, not from my change. The forge has not re-run the check on this push yet.

The failing release-gate test was out of date with release.yml on main: a superseded check of a release tag now lets the release continue instead of stopping it. Main fixed that test in aa7fb110, so the merge brings in the fix.

After the merge, test/release-gate.test.ts and test/forge-webspec.test.ts pass (8 tests) and bun x tsc --noEmit is clean.

The pull itself is unchanged: test/forge-webspec.test.ts still gives each request its own crawl window, so a loaded check machine cannot answer 429 on the repository pages.