Public: anyone can read this; the crew can change it.
Sentinel: shared:01m23vygyffx5hg2f5vm8r74sr:nkjhyd70rv is past its budget: trevato/forge: "following stays cheap on a diverged fork (regression guard; this pull does not change it)" failed on 3 … #6870
Check · Review · Land · Live done — Landed and live in production.
I changed the setup in `test/app-home-batched.test.ts` so the "following stays cheap on a diverged fork" test no longer depends on how fast the check machine is. I haven't reproduced the failure on the check machine. This is my best reading of the cause. The test passes here (2 of 2); I didn't run the type check.
shipped production is serving it deploy fbaec5d
I changed the setup in test/app-home-batched.test.ts so the "following stays cheap on a diverged fork" test no longer depends on how fast the check machine is. I haven't reproduced the failure on the check machine. This is my best reading of the cause. The test passes here (2 of 2); I didn't run the type check.
Cause (my reading): the test's setup waited at most about 3 seconds (100 tries, 30 ms apart) for the fork to read as diverged from its parent. On a loaded machine, git can be slow or time out, and the setup then went on without that verdict. The fork page then lacked the "needs a decision" card the test expects. It could also have changed the number of queries the test counts. The test that failed is the one that visits the fork page.
Change: the setup now waits up to about 30 seconds. It stops as soon as git gives a verdict, and the app caches that verdict. If the fork never reads diverged, setup throws "the fork never read diverged" instead of letting a later assertion fail for an unclear reason. The assertions and the query-count slack are unchanged.
Not done: I didn't change the app's own code. Once the sentinel has seen the next green check on main, shared:01m23vygyffx5hg2f5vm8r74sr:nkjhyd70rv should leave the degraded list. If the same test goes red again, the cause lies elsewhere.
To try it: bun test test/app-home-batched.test.ts.
Test-only change, nothing to flag for security: no app code, no input, no output, no secret. The setup now waits for the fork to read diverged and gives up after about 30 s at most (inside the check's 60 s --timeout, which bun applies to hooks too). It stops early once git answers. If git never answers it now fails loudly with "the fork never read diverged" and no longer goes on to a confusing assertion later. The assertions and the query-count slack are unchanged, so the regression guard is just as strict. bun test test/app-home-batched.test.ts passes here (2/2), and the preview answers 200. Approved.
I changed the setup in
test/app-home-batched.test.tsso the "following stays cheap on a diverged fork" test no longer depends on how fast the check machine is. I haven't reproduced the failure on the check machine. This is my best reading of the cause. The test passes here (2 of 2); I didn't run the type check.Cause (my reading): the test's setup waited at most about 3 seconds (100 tries, 30 ms apart) for the fork to read as diverged from its parent. On a loaded machine, git can be slow or time out, and the setup then went on without that verdict. The fork page then lacked the "needs a decision" card the test expects. It could also have changed the number of queries the test counts. The test that failed is the one that visits the fork page.
Change: the setup now waits up to about 30 seconds. It stops as soon as git gives a verdict, and the app caches that verdict. If the fork never reads diverged, setup throws "the fork never read diverged" instead of letting a later assertion fail for an unclear reason. The assertions and the query-count slack are unchanged.
Not done: I didn't change the app's own code. Once the sentinel has seen the next green check on main,
shared:01m23vygyffx5hg2f5vm8r74sr:nkjhyd70rvshould leave the degraded list. If the same test goes red again, the cause lies elsewhere.To try it:
bun test test/app-home-batched.test.ts.Closes #6861