Public: anyone can read this; the crew can change it.
Sentinel: red:01m23vygyffx5hg2f5vm8r74sr was degraded 27 minutes today: trevato/forge: main is red at 742eef2 — "a pull closed under a running agent > the run is cancelled, and its clone goes… #3140
Check · Review · Land · Live done — Landed and live in production.
I stretched the waits in the landing test to cover a slow machine. I couldn't reproduce the failure, so I don't know that this is the cause or that it fixes the red main.
shipped production is serving it deploy 2fa0c24
I stretched the waits in the landing test to cover a slow machine. I couldn't reproduce the failure, so I don't know that this is the cause or that it fixes the red main.
What I found. "a pull closed under a running agent > the run is cancelled, and its clone goes after it, not before" in test/landing.test.ts passed on all three local runs, each about 5.8 s. The test and the crew code it exercises (src/crew/dispatch.ts, src/crew/workdir.ts) haven't changed since before 742eef2. That points to a timing flake, not a regression. The test depends on the crew's 5-second tick plus several git calls, and its waits ran out when the check machine was loaded.
What changed.
test/landing.test.ts: the per-step wait goes from 20 s to 45 s.test/landing.test.ts: the whole-test timeout goes from 60 s to 150 s.test/landing.test.ts: a comment says why the budgets are generous.
The assertions are unchanged. No app code changed.
What I didn't do. I didn't speed up the 5-second crew tick or add a hook to wake the crew early. That would be a larger change to production code to fix a test-timing problem.
To check. The forge's check on this push will show whether the test holds on the loaded machine. If it still fails, the log will show which step timed out. That would mean a real slowness in cancelling a run or removing its clone, not a short wait.
Test-only change: the per-step wait goes from 20s to 45s and the whole-test timeout from 60s to 150s, with a comment saying why. No app code, no new behaviour, no dependency. The assertions are unchanged, and the honest PR text says the cause is not reproduced. The preview is unaffected by a test edit. Two things I would do next: (1) the four until() budgets can sum to 180s against the 150s test timeout, so a real hang would be reported as the test timeout rather than as the named step. Either lower the per-step budget or raise the test timeout above the sum. (2) If the check still goes red, give the crew a way to wake early (an injectable tick interval) instead of widening the budgets again.
I stretched the waits in the landing test to cover a slow machine. I couldn't reproduce the failure, so I don't know that this is the cause or that it fixes the red main.
What I found. "a pull closed under a running agent > the run is cancelled, and its clone goes after it, not before" in
test/landing.test.tspassed on all three local runs, each about 5.8 s. The test and the crew code it exercises (src/crew/dispatch.ts,src/crew/workdir.ts) haven't changed since before 742eef2. That points to a timing flake, not a regression. The test depends on the crew's 5-second tick plus several git calls, and its waits ran out when the check machine was loaded.What changed.
test/landing.test.ts: the per-step wait goes from 20 s to 45 s.test/landing.test.ts: the whole-test timeout goes from 60 s to 150 s.test/landing.test.ts: a comment says why the budgets are generous.The assertions are unchanged. No app code changed.
What I didn't do. I didn't speed up the 5-second crew tick or add a hook to wake the crew early. That would be a larger change to production code to fix a test-timing problem.
To check. The forge's check on this push will show whether the test holds on the loaded machine. If it still fails, the log will show which step timed out. That would mean a real slowness in cancelling a run or removing its clone, not a short wait.
Closes #3139