work-items:triage: cross-lane label race re-adds priority:needs-triage on an already-folded/blocked-by issue (#642)

[kyle-sexton]

This was generated by AI during triage.

Lane: triage. Category: operational.

Triggering example

#642: this lane folded it into #534 at 07:56:47Z (comment posted, blocked-by #534 recorded, priority: needs-triage stripped). At 08:12:05Z something re-added priority: needs-triage with no accompanying comment, putting it back in this lane's queue at the next cycle (cycle 9). Confirmed via the issue's label timeline (gh api .../issues/642/timeline) — exactly one label-add, one label-remove, one label-add, no comment on the second add. The other 3 items in the same cycle's queue (#639, #644, #645) each show exactly one label event (genuinely fresh), so this isn't a general re-triage sweep — just #642.

Observed vs expected

Observed: an already-triaged, already-blocked-by-umbrella issue got priority: needs-triage silently re-applied by some other process (identity is shared kyle-sexton across all automated lanes, so the actor field doesn't distinguish which one), costing this lane a wasted re-investigation cycle before the label timeline revealed it was already handled.

Expected: whatever process re-added the label should check for an existing blocked-by edge (or a prior triage comment) before re-labeling an issue as needing triage — or, defensively, this lane's queue-scan step should itself check for a pre-existing blocked-by edge / prior "This was generated by AI during triage" comment before re-processing an item, so a stray re-label doesn't cost a full re-investigation even when the source process isn't fixed.

Category

operational — cross-lane label hygiene gap. Low severity this instance (caught cheaply via the timeline check before any real re-work), but the failure mode (wasted re-triage cycles, or worse, a second contradictory routing decision on an already-decided item) recurs for free every time it happens, since nothing currently prevents it.

[kyle-sexton]

This was generated by AI during triage.

Triage (umbrella-fold, corrected) — same #538 "deterministic mechanics" class as #632/#633: checking for an existing blocked-by edge or prior triage comment before re-labeling/re-processing an issue is exactly the kind of pure mechanical pre-check a script should own instead of relying on every lane to remember by hand. Folding rather than routing standalone per the umbrella-fold rule.

Blocked by #538's decision. Not routed to needs-human individually.

[kyle-sexton]

This was generated by AI during triage (historic normalization, rule 8g — closing out the 55-issue historic sweep).

Checked #538 (deterministic-mechanics umbrella) — its scope (MACHINE-BEHAVIOR telemetry scripting, #502 upsert warning, other pure-mechanics extraction) doesn't explicitly name cross-lane label-write concurrency, and this issue's own body doesn't reference #538 either, so not folding without a textual link. Routing standalone: this is a genuinely open concurrency-control design question (how should concurrent same-identity lane instances avoid clobbering each other's label writes — a mutex/lock file, a single-writer convention, a compare-and-set / idempotent check-before-write pattern, or something else) rather than a single defaultable fix.

Note for whoever picks this up: this session independently observed circumstantial evidence consistent with this exact race class (see #632/#633's needs-human routing and this cycle's own #502 telemetry flag) — worth cross-referencing when scoping the fix.

[kyle-sexton]

Decision brief: cross-lane label-write race (concurrency control)

Human-operator decision brief. Not a triage routing decision — no labels/state changed by this comment.

Problem (2 sentences)

Concurrent same-identity automated lanes issue unconditional gh issue edit --add-label/--remove-label writes with no coordination, so a lane doing a read-modify-write on stale label state can silently re-apply priority: needs-triage to an issue triage has already routed (folded + blocked-by edge recorded). The open question is which concurrency-control shape to adopt so lane instances stop clobbering each other's label writes.

What's verified

• Symptom on babysit classifier: count_classified counts stale pipe-row classifications from non-thread review-summary comments #642 (verified directly from GET /issues/642/timeline, not just work-items:triage: cross-lane label race re-adds priority:needs-triage on an already-folded/blocked-by issue (#642) #646's body): the priority: needs-triage marker was stripped by triage at 07:56:47Z (matching the fold-into-source-control:babysit-prs: one shared authorship/finding/approval classifier + golden fixtures; gate script owns the merge-ready boolean (6-issue class) #534 comment at 07:56:46Z), then re-added twice more — 08:12:05Z and 09:01:14Z — each cleared minutes later, before the 09:04:04Z escalation to priority: high. That is two spurious re-adds after the item was already routed, not one; work-items:triage: cross-lane label race re-adds priority:needs-triage on an already-folded/blocked-by issue (#642) #646's body captured only the first. Every label event's actor is kyle-sexton (shared identity across all automated lanes), so the actor field cannot attribute which lane re-added.
• Direction of the clobber (load-bearing for the fix): the triage lane removes needs-triage and never adds it, and both re-adds carried no comment. So the clobbering writer is not the triage lane — it is a lost-update from some other lane's read-modify-write whose stale in-memory label set still carried needs-triage, or a hygiene sweep. A fix that only makes triage re-read before writing would not stop this symptom.
• Where the label-write logic lives: there is no seam verb that owns label writes. CONTRACT.md has no edit-labels/edit-item verb; the github adapter README documents label edits as raw gh issue edit <N> --add-label --remove-label run inline by each lane per its SKILL.md prompt text (plugins/work-items/tools/work-item-tracker/adapters/github/README.md, "Edit labels / assignees"). This is the same "logic lives in operator-maintained prompt text, not an atomic script" finding as work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values #632/work-items:triage: umbrella-fold routing misses the umbrella-side membership comment (item-side only, 3x this session) #633. That missing write chokepoint is why this is a design question rather than a one-line patch.
• No native atomic primitive: GitHub label writes are unconditional last-write-wins; there is no compare-and-set / conditional-write. So no option here — including a lock label/comment (option a) — gives true atomic mutual exclusion without heavy external infrastructure; each has some read-to-write (TOCTOU) window. This bounds what is achievable and is what makes the heavier options over-built for a symptom whose events are 16+ minutes apart.
• Existing partial infrastructure: a lease/claim protocol (assignee + lease-comment marker, CONTRACT.md "Lease protocol") already coordinates work claiming — but it is not applied to triage/label writes.

Options

(c) — RECOMMENDED — Idempotent check-before-write, on both the reader and writer paths.
Two complementary changes, both in-repo prompt text / a new in-repo seam verb (no cross-session or cross-repo shared state):

• Reader-side (absorbs this exact symptom now, regardless of who the clobberer is): the triage queue-scan skips re-investigation when the item already carries a blocked-by edge or a prior "generated by AI during triage" comment. This is fully within triage's control and guaranteed to neutralize a stray re-label — the item stops costing a re-investigation cycle even if the source writer is never fixed.
• Write-path (attacks the root, the lost update across all lanes): every lane re-reads current labels immediately before an --add-label write and skips the write when state already reflects the intended outcome. Because the write path is today an un-owned raw gh call re-remembered per lane, the durable form is to promote it to a shared in-repo edit-labels seam verb that does the re-read-and-diff, so the guard is enforced once rather than depended on in every lane's prompt.
• Tradeoffs: lowest complexity, no new shared state, no latency floor. It narrows but does not fully close the TOCTOU window for genuinely simultaneous writers — acceptable here because the observed races are minutes apart, and the reader-side check makes a slipped write harmless rather than costly. Reversible: prompt-text / single-verb change, trivially revertible.
• Honest limit (shared by all prompt-text options): until the write-path guard is a seam verb, it is remembered, not enforced — same class of "every lane must remember by hand" gap as work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values #632/work-items:triage: umbrella-fold routing misses the umbrella-side membership comment (item-side only, 3x this session) #633. The seam-verb promotion is what converts it from remembered to enforced.

(a) Mutex / lock (a .triage.lock file in-repo, or a GitHub-native lock via a reserved label/comment convention).
A lane acquires the lock before writing, releases after. Tradeoffs: higher complexity; a repo lock file needs a commit/push cycle (latency, and its own write race); a label/comment lock still has a TOCTOU acquire window (no atomic CAS) so it does not deliver the mutual exclusion it appears to. Introduces stuck-lock failure modes (crashed lane holding the lock) needing TTL/steal logic — reinventing the existing lease protocol. Over-built for a minutes-apart symptom. Reversible but leaves lock-convention residue to clean up.

(b) Single-writer convention (only one lane instance may run label-writing triage at a time, enforced externally).
Could reuse the existing lease protocol as the single-writer token. Tradeoffs: strongest correctness if enforcement is real, but "enforced externally" is the catch — with shared kyle-sexton identity and independent lane schedulers there is no current external enforcer, so in practice it degrades to a remembered convention. Serializes throughput (latency) even when lanes touch disjoint issues. Reversible as policy; higher coordination cost. Worth revisiting only if idempotent checks prove insufficient under real concurrency.

(d) Accept as known limitation + periodic reconciliation sweep.
Do not prevent; run a periodic sweep that clears needs-triage from any issue already carrying a blocked-by edge / prior triage comment. Tradeoffs: simplest to reason about, but leaves a window where a mis-labeled item is picked up and re-investigated (or, worse, re-routed to a contradictory decision) before the sweep runs — it manages the symptom rather than removing the wasted cycle. Effectively a weaker, lag-delayed version of (c)'s reader-side check. Reversible. Reasonable fallback if (c) is deferred, not a substitute for it.

Cross-links

• work-items:triage: routing step doesn't strip conflicting priority: labels before adding the default, allowing duplicate priority-axis values #632 (work-items:triage: routing step doesn't strip conflicting priority: labels…) and work-items:triage: umbrella-fold routing misses the umbrella-side membership comment (item-side only, 3x this session) #633 (umbrella-fold routing misses the umbrella-side membership comment) — per work-items:triage: cross-lane label race re-adds priority:needs-triage on an already-folded/blocked-by issue (#642) #646's own note, these are sibling instances of the same class: pure deterministic label/routing mechanics currently carried in prompt text that a script/seam should own (the #538 "deterministic-mechanics" umbrella; both routed needs-human). The recommended seam-verb promotion in option (c) is the same structural remedy those raise.
• babysit classifier: count_classified counts stale pipe-row classifications from non-thread review-summary comments #642 is the concretely-affected issue (timeline above). ops: loop-lane telemetry — running per-lane status (babysit / triage / work) #502's telemetry flag was referenced by work-items:triage: cross-lane label race re-adds priority:needs-triage on an already-folded/blocked-by issue (#642) #646's second comment as circumstantial evidence of this race class; not load-bearing for the fork and not investigated here.

The decision for the operator

Adopt option (c) — reader-side defensive queue-scan check plus a write-path re-read promoted to a shared in-repo edit-labels seam verb — unless you want the stronger serialization guarantee of (b)/(a) and accept their infrastructure and latency cost. (d) is an acceptable interim if (c) is deferred.