Development record
2026-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.
2026-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.
Frontmatter
| id | dcn-2610280036019459 |
|---|---|
| type | decision |
| date | 2026-10-28 |
.abcd/work/decisions/dcn-2610280036019459-resolve-iss-2610110253059544-as-fixed-on.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-2610110253059544gitutil'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.
- iss-2610181802344551A context-bound git command can outlive its caller's deadline: isolatedGitContext runs the partial-clone guard (lazyFetchGuard) first, and the guard's own git version probe and its floor-config read run with no context, so a git that hangs holds a caller on a deadline (the status verb, the prompt hook's reads) for as long as git hangs, though the command itself is killed at the deadline. Found when TestRootCommitContextKillsGitAtTheDeadline, run alone, took 20 s against a 500 ms deadline because its hanging fake git answered the guard's probes.