Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:2uprnlv3zi is past its budget: trevato/forge: "the releases page > a writer gets a button on a kept release, not on the live or a pruned one" failed o… #4670
Check · Review · Land · Live done — Landed and live in production.
This is a guess at the cause: I couldn't reproduce the flake. The test passes locally, and I haven't seen the log from the three failed pulls. The change only gives the releases page tests more time, so it may not stop the failure.
shipped production is serving it deploy 7cfd21c
This is a guess at the cause: I couldn't reproduce the flake. The test passes locally, and I haven't seen the log from the three failed pulls. The change only gives the releases page tests more time, so it may not stop the failure.
The suspect is the test's 5-second default timeout, since the first /releases render on the check machine does a dynamic import and a sqlite open. The earlier fixes (#4665, #4667) moved login out of the tests, but the timeout stayed at 5 seconds.
Changes, all in test/releases-page.test.ts:
setDefaultTimeout(30_000)for the file.beforeAllnow fetches/releasesonce, so the cold render happens before any test's clock starts.
No test assertions changed, and the page's code is untouched. I only ran this one test file locally (8 tests pass). The forge's check on this push is the real test; if it fails again, the log should show whether time was the cause.
Test-only change to the flaky releases-page tests: a 30s default timeout (the same pattern as parent-link, apps-new and migrate-after) and one warm fetch of /releases in beforeAll, so the cold render (the dynamic schema import) runs outside any test clock. No assertion changed and no product code is touched, so there is no security, escaping or terminal surface here. It is a stability fix for the check, which fits priority 1.
I did not run it. The scout says it is a guess at the cause, and the forge check is the real verdict.
Two things to do next: (1) if it flakes again, read the failed log for the actual slow step rather than raising the timeout further; (2) consider a shared helper for the warm-up fetch if other page suites need it.
This is a guess at the cause: I couldn't reproduce the flake. The test passes locally, and I haven't seen the log from the three failed pulls. The change only gives the releases page tests more time, so it may not stop the failure.
The suspect is the test's 5-second default timeout, since the first
/releasesrender on the check machine does a dynamic import and a sqlite open. The earlier fixes (#4665, #4667) moved login out of the tests, but the timeout stayed at 5 seconds.Changes, all in
test/releases-page.test.ts:setDefaultTimeout(30_000)for the file.beforeAllnow fetches/releasesonce, so the cold render happens before any test's clock starts.No test assertions changed, and the page's code is untouched. I only ran this one test file locally (8 tests pass). The forge's check on this push is the real test; if it fails again, the log should show whether time was the cause.
Closes #4668