Development record
Link and Plan do unlocked read-modify-writes on records RecordGrounds now locks
Link and Plan do unlocked read-modify-writes on records RecordGrounds now locks
Found by the round-3 adversarial security review of build/itd-179, and recorded BELOW THE FINDING BAR by the reviewer's own judgement -- worth keeping, not worth acting on yet.
internal/core/intent/lifecycle.go:398 (Link) and :207,227 (Plan) do
unlocked read-modify-writes on records that RecordGrounds also writes
(planned/, drafts/). So the lock added in ac48db99 serialises RecordGrounds
against itself and against stampPlanned, but not against these two peers.
Why it is not a finding: the reviewer could not demonstrate a loss in 400 trials, against a loss within 3 trials for the case the lock actually fixed. That gap in reproducibility is the whole record -- the theoretical race is real, the practical window is not demonstrable, and the honest thing is to say so rather than either fix it blind or drop it.
Pre-existing on main. The branch's new writer is the one that DOES lock.
Grounds
- declined: the finding is carried whole by iss-127; this would be wrong if iss-127 were closed without answering it
Frontmatter
| id | iss-2608301306587401 |
|---|---|
| type | issue |
| lifecycle | wontfix |
| severity | nitpick |
.abcd/work/issues/wontfix/iss-2608301306587401-link-and-plan-do-unlocked-read-modify.md
open on GitHub ↗ · commit history ↗
mentions2
- iss-127repo-local load-modify-write sites remain unguarded after the iss-101/102 class fix: intent transitions (review.go, lifecycle.go — strongest candidate), ahoy config.json stepConfigValues, gitignore/marker block rewrites, and the CHANGELOG release path all do load-mutate-write without a lock; they lack the home-global cross-worktree exposure the fixed sites had, so risk is same-worktree concurrency only
- itd-179The reasoning behind what was pursued no longer evaporates at the gate — readiness and triage record grounds for the conjecture, not only the decision