Twinned from https://github.com/cfsh/ninefold/issues/727 by tools/beads/import_github.py's reconcile pass.
@aedanpope answered seven needs:direction issues at 07:03-07:07 today. At 07:35 all seven still carried the label, so the CTO reported them back to him as *"still waiting on you"*. #718 was closed and still labelled.
A label that means "waiting on X" is set by one actor and cleared by nobody. The comment that satisfies it is not the state; the label is. So the queue only grows.
| label | set by | cleared by |
|---|---|---|
| needs:direction | the session that asks | nobody — @aedanpope's answer is a comment |
| active | /triage or the CTO on assignment | nobody — survives the issue being CLOSED |
The CTO has been hand-stripping stale active labels at every reap tick for a day; that is the same bug, hand-patched.
needs:direction — a comment from @aedanpope on a needs:direction issue is the answer, by definition of the label (*"one-word steer wanted from Aedan"*). Clearing on his comment is mechanical and needs no judgement about whether the answer was sufficient: if his reply raises a new question, the session re-labels.active — closing the issue should clear it. There is no state where a CLOSED issue is legitimately in a session's current chunk.⚠️ Do not "fix" this by having readers cross-check. That is what the CTO does now, and it is why this was noticed rather than prevented. The label is the interface; a label that lies has to be repaired at the writer, not compensated for at every reader.
⚠️ Second, smaller trap for whoever builds this: gh issue list --label X reads an eventually-consistent index and lags gh issue edit by seconds — two issues showed as still-labelled immediately after a successful removal, and gh issue view on the same objects showed them clear. Verify label writes with view, not list, or the fix will look flaky in its own tests.
Related: #684 (the poll telling a session with four open PRs to wrap up — the same class, a signal nothing retracts).
None.
No comments.