Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2tvkfbq2b9 is past its budget: trevato/forge: "origins on the web > the repo header wears the where strip and the About rail one block" failed on 3 pu… #6963
Check · Review · Land · Live done — Landed and live in production.
This is a best guess at the cause, not a confirmed fix. I couldn't reproduce the failure: the suite passed three times normally and three times with six busy-loop processes running alongside.
shipped production is serving it deploy 9b6b076
This is a best guess at the cause, not a confirmed fix. I couldn't reproduce the failure: the suite passed three times normally and three times with six busy-loop processes running alongside.
What changed: test/web-origins.test.ts now calls setDefaultTimeout(30_000). Every test in the file does a real git fetch against a second forge and renders full pages, and bun's 5 s default applied to all of them. My reading is that on a check machine where the event loop is stalled (see #6961), the repo-home test in that suite can run past 5 s. That test is the first to render a freshly mirrored repo's full page, with its tree and README. The suite itself takes about 1.5 s here.
What I left out: I found no other time-, disk- or clock-dependent code on the path that test checks.
Not verified: no failing log was available, so I haven't confirmed the timeout is the cause. If the test still fails after this, the failure message will name the assertion that broke. The test and the app code are otherwise unchanged. I ran only bun test test/web-origins.test.ts (31 pass), not the type check or the full suite, and left that to the forge's check.
How to check: run bun test test/web-origins.test.ts, then watch whether shared:01m23vygyffx5hg2f5vm8r74sr:2tvkfbq2b9 leaves the degraded list after the next green check.
Test-only, one-file change. It raises the default timeout to 30 s in test/web-origins.test.ts, the same way about ten other suites already do. The preview answers 200 at /. The cause is a best guess (the author could not reproduce the failure), and the author says so, so this may not be the fix. Next: (1) if the test fails again, read the assertion in the log rather than raising the timeout further. (2) Find the slow step, most likely the first full render of a freshly mirrored repo, and time it so a budget can be set per test (#1242).
This is a best guess at the cause, not a confirmed fix. I couldn't reproduce the failure: the suite passed three times normally and three times with six busy-loop processes running alongside.
What changed:
test/web-origins.test.tsnow callssetDefaultTimeout(30_000). Every test in the file does a real git fetch against a second forge and renders full pages, and bun's 5 s default applied to all of them. My reading is that on a check machine where the event loop is stalled (see #6961), the repo-home test in that suite can run past 5 s. That test is the first to render a freshly mirrored repo's full page, with its tree and README. The suite itself takes about 1.5 s here.What I left out: I found no other time-, disk- or clock-dependent code on the path that test checks.
Not verified: no failing log was available, so I haven't confirmed the timeout is the cause. If the test still fails after this, the failure message will name the assertion that broke. The test and the app code are otherwise unchanged. I ran only
bun test test/web-origins.test.ts(31 pass), not the type check or the full suite, and left that to the forge's check.How to check: run
bun test test/web-origins.test.ts, then watch whethershared:01m23vygyffx5hg2f5vm8r74sr:2tvkfbq2b9leaves the degraded list after the next green check.Closes #6951