Development record
Two tests fail under machine load rather than on a defect: TestReadOwedHonoursDeadline in internal/core/autonomy found the read marked complete when the forge timed out, and TestHookSessionEndRetriesATransientRootFailure in internal/surface/cli ran out of retry time and staged nothing, both during a gated preflight at load 17 on ten cores
Two tests fail under machine load rather than on a defect: TestReadOwedHonoursDeadline in internal/core/autonomy found the read marked complete when the forge timed out, and TestHookSessionEndRetriesATransientRootFailure in internal/surface/cli ran out of retry time and staged nothing, both during a gated preflight at load 17 on ten cores
Diagnosis 2026-10-25
The first reading above was wrong: load was not the cause. All three tests below also fail on their own at a load of 5, on main at 2e03c61e4 and on a commit from 2026-10-20, because each git process takes tens of milliseconds to start on this machine and a few dozen of them outlast the budgets the tests set.
TestReadOwedHonoursDeadline(internal/core/autonomy) shows a real defect. Once the 150ms budget has passed, the owed-work reader's git reads fail. The branch listing and the reflog and worktree reads then take the failures to mean "nothing there", so the reading came back complete with no own branches. The verdict should instead fail open and name the cut.TestEachForgeLookupEndsAtTheBudget(internal/core/claim) measured the lookup's deadline from before the status fetch, whose git work is the machine's to time, not the budget's.TestHookSessionEndRetriesATransientRootFailure(internal/surface/cli) tests the retry under the real 1.2-second budget. On this machine one detection through the test's git shim costs most of that, so no retry fits.
The same failure is filed from another worktree as iss-2610241829569682 (not yet on the default branch).
Grounds
- pursued: we expect the three tests to pass on a machine where git starts slowly and the owed-work check never to report a cut-short reading as whole; a run where a git read past the deadline still yields Incomplete false would show it wrong
Evidence 2026-10-25 (measured by a second session on the same machine)
With no preflight running, at a load of about 6 on ten cores:
- A push to a file-path remote took about 0.4 s and a fetch about 0.33 s, both at under 10% CPU. Launching a git transport helper took about 270 ms at 3% CPU, against 23 ms for
git --version. - TestEachForgeLookupEndsAtTheBudget ran 74 git processes, totalling 6.4 s of git time, and failed on every run on a clean copy of the default branch, even alone. CI passed the same commit.
- The endpoint scanner was the top CPU consumer.
So the time goes to git's local transport rather than to CPU, which is why the sub-second budgets failed at low load.
Frontmatter
| id | iss-2610241911001655 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | major |
.abcd/work/issues/resolved/iss-2610241911001655-two-tests-fail-under-machine-load-rather.md
open on GitHub ↗ · commit history ↗
mentions4
- dcn-26102501090703422026-10-25 — The records branch docs/review-set-and-planning-autonomy is parked, unpushed, from 2026-10-25 01:15 UTC. Four preflights failed on tests the branch does not touch: two timed out at the load gate, and two failed in main's suite. Those failures were the deadline and forge-budget tests under the live reservation iss-2610241911001655, three packages past their 20-minute timeout, and the stop-hook tests in the daylight-saving fold (iss-2610250107576049). The release cut's merge hold starts at 02:30 UTC. The branch is rebased and gets one gated preflight once that fix is on main and the hold has lifted.
- iss-2610241829569682TestReadOwedHonoursDeadline (internal/core/autonomy/owedread_test.go:1198) failed in a preflight on a loaded machine on 2026-10-24 (load near 20, other preflights running): the read it cut short came back with incomplete false while its notes said 'the local branches could not be listed | the pull requests were not read (the forge did not answer within 10s), so the check judged from disk', so either a read cut short under load does not mark itself incomplete, or the test's deadline races the machine. A test that fails under load blocks every preflight that meets it, whatever the branch changed.
- iss-2610251203588744This session (abcd-58) captured and fixed three load-sensitive test failures as three new records on fix/unit-stage-budget, without first running abcd peers or checking the peer branches. A peer's chore/capture-holdups-3fee already held the same finding, iss-2610241911001655, reserved at 10:01 and fixed in the same three files. So the work was done twice, and the two branches would have conflicted. The duplicates were dropped before anything was pushed.
- iss-2610251853204621TestNothingIsMarkedPastTheHooksDeadline (internal/core/claim) fails under -race on a loaded machine. It gives the whole status read a real 400ms deadline, but it tests only that a block marked after the hook's deadline keeps nothing. The read itself (git through the status state, then render) outran 400ms in the joint preflight's race stage on 2026-10-25, so PromptNotes returned 'status unavailable' and the test failed before it reached the marking. It is the same class as iss-2610241911001655: a load-dependent budget standing in front of the behaviour under test.