[Bug]: Runs frequently stall midway without automatic escalation or notifications

[jiangnan-ten]

Deployment type

Official App

What happened?

如图，agent 开始一个sub issue，如果遇到需要审核或者block的情况，就完全停下来了，也不会让leader或者用户或者指定的agent去推进

看是我使用的方式不对 还是？

Steps to reproduce

如图

Screenshots (optional)

No response

Additional context (optional)

[vicksiyi]

Thanks for the report. I opened PR #5625 with a fix: #5625

Root cause: child issues entering in_review or blocked only emitted ordinary status-change notifications, so parent coordinators could miss them unless they were already subscribed.
Fix: child review/block transitions now post a parent handoff and route it to the parent owner: agent/squad assignees get the existing deduped task wake, and member assignees get an action-required inbox item pointing at the child.
Validation: go test ./internal/handler -run 'TestChildAttention|TestBatchChildAttention|TestChildDone|TestBatchChildDone'; go test ./internal/handler. make check-worktree exited 0 locally but printed that Docker was unavailable during the PostgreSQL check.

I will keep an eye on CI and review feedback.

[yanbohon]

Confirmed again on the Official App on 2026-07-27/28 with a staged squad workflow.

This reproduction isolates the problem from the earlier configuration and runtime failure modes:

• The coordinating parent issue was assigned to a squad and remained in_progress.
• Stage 1 reached 2/2 done; the existing child-terminal handoff correctly posted a system comment on the parent, woke the squad leader, and the leader promoted Stage 2. This confirms that parent ownership, squad routing, and the runtime were healthy.
• The Stage 2 executor task then completed successfully with no task error and moved its child issue to in_review. Its PR was open, clean, linked to the child, and carried close intent.
• No parent system handoff was posted for that in_review transition, no squad-leader task was queued, and the next stage remained in backlog.
• All relevant runtimes were online. The executor tasks were completed, not failed or cancelled.

The effective state was:

executor task completed
  -> child issue in_review
  -> no parent handoff / no reviewer task / no squad-leader wake
  -> current stage remains 0/1 done
  -> next stage remains backlog

The current workaround is to encode a prose protocol in squad instructions: the leader must copy a delivery rule into every child description, the implementer must explicitly mention a reviewer in its final comment, and an approving reviewer must explicitly mention the squad leader. This works through comment mentions, but it is brittle because squad instructions are injected only into the leader, not member agents, and the platform does not enforce the handoff.

PR #5625 is the exact minimal behavior needed here. Please treat this as an additional live acceptance case for that PR:

1. A child transition to in_review posts one parent-level attention handoff.
2. A squad-assigned parent wakes its leader exactly once through the existing deduped path.
3. The transition does not close the stage barrier; the leader/reviewer still decides whether to request rework or merge/complete the child.
4. The later child done transition continues to use the existing terminal stage-barrier handoff and advances the workflow normally.

This is not a request to auto-mark review as done. It is a request to guarantee that in_review has a deterministic next actor instead of becoming a silent terminal point in an otherwise automatic staged workflow.

[yanbohon]

Additional live acceptance case from the Official App on 2026-07-28: PR #5625 covers the first child transition into in_review / blocked, but a staged squad workflow can still stall at later handoffs while the child remains in the same status.

Observed sequence:

1. The squad parent remained in_progress; its leader and all member runtimes were online.
2. The child was already in_review after implementation delivery.
3. The reviewer posted REQUEST_CHANGES and explicitly mentioned the implementer. Rework started correctly, confirming mention routing and runtimes were healthy.
4. The implementer completed the requested changes, but did not explicitly mention the leader. No parent handoff or leader task was created; a human had to mention the leader.
5. The reviewer then posted APPROVE, again without a leader mention. No parent handoff or leader task was created; a human had to mention the leader again.
6. The leader assigned QA. QA posted a final GO; the child remained in_review, the leader became idle, and no parent handoff was created. The workflow again required a manual leader mention to close the stage and release the next one.

The effective residual failure is:

child already in_review
  -> implementer/reviewer/QA task completes with an action-bearing result comment
  -> no child status transition
  -> no parent coordinator handoff
  -> squad leader remains idle until a human manually @mentions it

This is distinct from, but adjacent to, the transition-level fix in #5625. A state transition can wake the coordinator once, but multi-role review workflows have later same-state handoffs (changes fixed, APPROVE, GO / NO_GO) that are currently encoded only as prose comments. The backend cannot reliably infer these outcomes from free text.

Suggested acceptance behavior for a follow-up:

• Provide a first-class task/comment handoff or verdict outcome with an explicit next target (agent, squad leader, or parent coordinator).
• When a child run finishes at an action boundary without another explicit target, allow it to hand control back to the parent coordinator exactly once through the existing deduped wake path.
• Preserve direct handoffs such as reviewer REQUEST_CHANGES -> implementer without unnecessarily waking the parent leader.
• Do not auto-mark the child done; the coordinator still owns stage closure and the next assignment.

This seems related to the broader dispatch/callback contract proposed in #4596, while #5625 remains the correct minimal fix for status-transition handoffs.

[zqbake]

Confirmed again on the Official App with a current-version staged Squad workflow. This is a new live reproduction of the transition-level failure described here, collected after the earlier reports and after the latest local daemon/CLI release.

Environment

• Deployment: Official App
• Multica daemon/CLI: v0.4.29 (c670e0549, built 2026-08-18)
• Codex runtime: codex-cli 0.147.0
• The daemon was running; the leader runtime was online and actively processing other tasks.
• The hosted backend build SHA is not exposed by the current CLI.

Minimal timeline (UTC, 2026-08-15)

1. The Squad-assigned parent leader's prior run finished at 07:26:11Z.
2. A child assigned directly to a worker agent started at 07:24:56Z.
3. The worker completed successfully at 07:38:34Z and its result explicitly reported that the child was moved to in_review.
4. At child completion there was no pending parent-leader run, so this was not pending-task deduplication.
5. No parent handoff or parent-leader run was created after the child entered in_review.
6. The next parent-leader run appeared only at 10:19:10Z, with attribution direct_human, after a user comment requesting continuation.

Effective sequence:

parent leader idle
  -> direct-agent child completes successfully
  -> child enters in_review
  -> no parent handoff / no parent task row
  -> daemon has nothing to claim
  -> human comment creates the next leader run

This isolates the failure before daemon claim/launch: the parent task was never enqueued.

Stage-frontier amplification observed on 2026-08-19

Stage 8:  3 x in_review
Stage 9:  5 x in_review
Stage 10: 1 x in_review
Stage 11: 4/4 done

The non-terminal lower frontier correctly prevents the later terminal stage from closing the barrier, so the missing review-ready wake leaves the coordinator idle and makes repeated manual continuation visible over multiple stages.

Expected behavior

On the first direct-agent child transition into in_review, post one parent-level attention handoff and enqueue the Squad parent leader exactly once through the existing deduped path. Do not mark the child done or advance the stage automatically; the leader still owns review and stage closure.

This is exactly the transition-level behavior proposed in #5625, which remains open. Please treat this as current acceptance/reproduction data for that fix. It also supplies the focused version and timeline requested in #7185.