Development record
gitutil's one-time git version probe (internal/gitutil lazyfetch.go) runs with no deadline and under a process-wide lock. So the first git call of a process whose git hangs blocks in that probe, and every other git call waits on the lock behind it. For the status line this means a hung git ends the verb at its 500ms overall limit with the wrong message, and the hanging git version child is never killed, so one is left behind on every refresh. Found by the 2026-10-11 drain lane for iss-2610090642407850: a test's hanging fake git, answering the probe, blocked every git in its test process for 30s.
gitutil's one-time git version probe (internal/gitutil lazyfetch.go) runs with no deadline and under a process-wide lock. So the first git call of a process whose git hangs blocks in that probe, and every other git call waits on the lock behind it. For the status line this means a hung git ends the verb at its 500ms overall limit with the wrong message, and the hanging git version child is never killed, so one is left behind on every refresh. Found by the 2026-10-11 drain lane for iss-2610090642407850: a test's hanging fake git, answering the probe, blocked every git in its test process for 30s.
Frontmatter
| id | iss-2610110253059544 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2610110253059544-gitutil-version-probe-has-no-deadline.md
open on GitHub ↗ · commit history ↗
mentions2
- dcn-26102800360194592026-10-28 — Resolve iss-2610110253059544 as fixed on main rather than landing the 12 October gitutil-probe branch. Main's iss-2610181802344551 work already does what the issue's remedy asks: the version probe runs under the caller's deadline where it has one (atLeastContext) and within 30 seconds where it has none (probeGitVersion), the lock is not held while git runs, git is killed at cancel (CommandContext with WaitDelay), a failed probe is not cached, and TestAContextBoundReadEndsAtItsDeadlineWhileTheVersionProbeHangs proves the call returns by its deadline and no git is left behind. The branch's 250ms fixed deadline conflicts with that design, and rebasing it would mean rewriting it against code that already answers the issue. The branch stays as it is, unmerged.
- iss-2610090642407850TestStatuslineSlowBranchStillRendersThePartialRow failed once at 0.34s in a local landing preflight under a load average above 50; a retry passed. It is the sibling of TestStatuslineSlowPreviousCommandIsStopped, whose wall-clock budget was fixed in iss-2610080243367006, but that fix did not reach this test, so the same family can still fail under a loaded host.