Wave digest can finalize twice when a member is done-but-unreported

[CrysisDeu]

Symptom

A multi-member wave can emit its final digest twice, or emit a premature partial "wave finished", when one member's SubagentInfo.done = True is set before that member's terminal report reaches the gateway completion consumer (_subagent_done).

Mechanism (pre-existing on main)

batch_members_pending() treats a member as no longer outstanding the moment info.done flips, but the member's done-count contribution to the consumer's bp["done"] only lands when its (shielded, possibly slow) terminal report task actually invokes the consumer. In that gap, ANY sibling completion that reaches the consumer sees done < total AND batch_members_pending() == False, so the last-member fallback finalizes early; the in-flight report then re-creates the batch-progress record and "finalizes" the same batch again.

This is reachable with two RUNNING members alone (member A done-but-unreported while member B's report executes the consumer) — it predates the Stop-all work in #8270 and is merely easier to hit now that stopped/unqueued members also flow through the consumer. The synthetic unqueue announces added for #8270 already bridge their own version of this window with _batch_unqueued_pending + a per-batch bounded lock; NORMAL terminal reports have no equivalent "done-but-unreported" accounting.

Direction

Extend the same protocol to normal terminal reports: count a member as outstanding from done=True until its report enters the consumer (e.g. a per-batch done-but-unreported count decremented at the top of the report path), or make the consumer's finalize decision consult report-task liveness. Needs care around the report shield, _force_reap, and cancel-recovery paths — which is why it is split out rather than folded into #8270's fix.

References

• Consumer fallback: src/kiro_crew/slack/gateway.py (_last = ... not batch_members_pending(batch_id))
• Report path: src/kiro_crew/subagent_manager/terminal.py
• The Stop all leaves queued subagents running #8270 bridge for unqueued members: src/kiro_crew/subagent_manager/cancellation.py::_unqueue_impl

Found by a model review lane while verifying the #8270 fix.

[github-actions]

Automated triage summary — generated from the issue text alone, before any maintainer has read it. Treat every line as a starting point, not a verdict.

A multi-member wave can finalize its digest twice or emit a premature partial "wave finished" when a member is marked done before its terminal report reaches the completion consumer; a sibling completion arriving in that gap triggers early last-member finalization, then the in-flight report re-finalizes the same batch. Reproducible with two running members.

Possibly already reported

• Stop all leaves queued subagents running #8270 (Stop all leaves queued subagents running)

If one of these is the same problem, say so and we will close this as a duplicate.

_{Posted by issue-summary.yml. The model had no access to the repository — it read only this issue and the titles of recent ones.}

[CrysisDeu]

🤖 Kiro Crew Auto-Pipeline [operator: CrysisDeu#0c98c3a2]: Routing to needs-investigation. Confirmed on current main: the consumer fallback at slack/gateway.py still finalizes on done < total and not batch_members_pending(batch_id), and batch_members_pending keys off info.done while the done-count only lands when the shielded terminal report reaches the consumer, so the done-but-unreported window is real. The _batch_unqueued_pending bridge this issue proposes to generalize does not exist on main yet — it lives on open PR #8556 (#8270), so the shape of the fix depends on how that lands. Beyond that dependency, closing the window needs a protocol decision (per-batch outstanding-report counter vs consulting report-task liveness) that has to hold across the report shield, _force_reap, and cancel-recovery — an un-reproduced race with design judgment, not a mechanical fix. Human should look at: whether the finalize decision should move entirely onto the report path (single source of truth) once #8556 merges, and add a two-running-member regression test that delays A's report while B's completes.

[CrysisDeu]

🤖 Kiro Crew Auto-Pipeline [operator: CrysisDeu#0c98c3a2]: Re-triage -- staying needs-investigation but the dependency changed. PR #8556 closed unmerged (superseded by #8327 for the stop-all half, so the 'generalize _batch_unqueued_pending' plan is moot -- that helper does not exist on main). The race itself is still reachable on main (slack/gateway.py consumer fallback vs waves.py::batch_members_pending_impl dropping a member the moment done flips). The fix is now carried by open PR #9008 (_reports_in_flight registry + batch_reports_in_flight_impl), which names this issue in its body but has no closing keyword, so the linkage is invisible in the graph. Reviewers there flag one remaining gap: the recovery-failed arm in cancellation.py flips done=True without arming the hold. Not dispatching a second implementation; will re-check after #9008 resolves.