Summary

• Problem: After markSubagentRunTerminated kills a subagent run, the mirrored task rows stay stuck in running indefinitely. The linked report describes both the parent runtime='subagent' row and the child runtime='cli' row for the same run. The cancel path returns early because the run is already gone; maintenance had no subagent-run lookup so neither row could be cleared without a manual DB fix. Issue Bug: killed subagent run can leave task_runs stuck in running, with tasks cancel and maintenance unable to clear it #90444.
• Root Cause: The kill path persisted terminal subagent-run state (endedAt, cleanupHandled, suppressAnnounceReason) but never called failTaskRunByRunId to close the mirrored task rows. Writing failTaskRunByRunId immediately in the kill path would fix the stuck rows but opens a kill-vs-complete race: if a lifecycle COMPLETE event arrives concurrently, completeTaskRunByRunId cannot transition failed → succeeded because shouldApplyRunScopedStatusUpdate blocks that direction, leaving the row permanently wrong.
• Fix: Decouple the two concerns. Kill path writes setDetachedTaskDeliveryStatusByRunId(not_applicable) immediately — killed runs never reach the announce flow. Task-row status finalization is deferred to maintenance, which reads terminal run state from a merged SQLite+memory snapshot via a new optional getSubagentRunEndedAt hook on TaskRegistryMaintenanceRuntime. When endedAt is set for a run, shouldMarkLost returns true early — before the 5-minute TASK_RECONCILE_GRACE_MS window — for both runtime='subagent' and same-run runtime='cli' peer rows, so maintenance marks them lost on the next sweep (≤ 60 s). The snapshot is SQLite-backed so CLI maintenance (openclaw tasks maintenance --apply) also resolves stuck rows. A shouldApplyRunScopedStatusUpdate change allows lost → succeeded, and the lost → succeeded upgrade also clears the stale error and resets cleanupAfter to the succeeded retention window.
• What changed:
  • src/agents/subagent-registry-run-manager.ts — kill loop: remove failTaskRunByRunId; keep setDetachedTaskDeliveryStatusByRunId(not_applicable).
  • src/tasks/task-registry.maintenance.ts — add optional getSubagentRunEndedAt hook; populate a per-sweep SQLite+memory snapshot via getSubagentRunsSnapshotForRead; terminal-run early-exit in shouldMarkLost and hasBackingSession now covers both runtime='subagent' and same-run runtime='cli' peer rows.
  • src/tasks/task-registry.ts — allow lost → succeeded in shouldApplyRunScopedStatusUpdate; clear lost-derived error and reset cleanupAfter on the upgrade.
  • src/agents/subagent-registry.test.ts — add mock for setDetachedTaskDeliveryStatusByRunId; update killed-run test.
  • src/tasks/task-registry.maintenance.issue-60299.test.ts — add getSubagentRunEndedAt to harness; add five regression tests for #90444.
  • src/tasks/task-registry.test.ts — add regression for kill → maintenance lost → late COMPLETE → succeeded with field-level assertions.
• What did NOT change (scope boundary):
  • The completion path (safeFinalizeSubagentTaskRun, completeTaskRunByRunId) is unchanged.
  • The kill-vs-complete race handler in subagent-registry-lifecycle.ts is unchanged.
  • Config surface unchanged. Plugin surface unchanged. No new config keys or deps.

Reproduction

1. Register a subagent run (registerSubagentRun) which creates mirrored running task rows.
2. Kill it via markSubagentRunTerminated — the kill path persists terminal state to SQLite and calls persist().
3. Attempt cancel on the task — returns early because the subagent run is already gone.
4. Run a maintenance sweep — before this PR, maintenance had no subagent-run lookup and saw the session entry still present, so hasBackingSession returned true and both rows stayed running.
5. Before this PR: both rows stay stuck in running with no automatic recovery path.
6. After this PR: kill path writes deliveryStatus = not_applicable immediately; the next maintenance sweep loads a SQLite+memory snapshot, finds endedAt set, and marks both the subagent row and any CLI peer row lost. A late lifecycle COMPLETE then upgrades lost → succeeded and clears the lost-derived error and cleanup window.

Real behavior proof

Behavior addressed (#90444): killed subagent task rows (both parent runtime='subagent' and child runtime='cli') no longer stay stuck in running — maintenance detects the terminal run record via a SQLite-backed snapshot and finalizes the rows on the next sweep, without the kill-vs-complete race that would occur if failTaskRunByRunId were called directly in the kill path.

Real environment tested (Linux, Node 22 — Vitest against the production kill path, maintenance runtime, and hasBackingSession logic): markSubagentRunTerminated driving the real subagent-registry-run-manager; runTaskRegistryMaintenance driving the real hasBackingSession with the new getSubagentRunEndedAt hook; markTaskLostById + markTaskTerminalByRunId exercising the lost → succeeded transition.

Exact steps or command run after this patch: node scripts/run-vitest.mjs src/tasks/task-registry.maintenance.issue-60299.test.ts src/tasks/task-registry.test.ts src/agents/subagent-registry.test.ts src/agents/subagent-registry-lifecycle.test.ts

Evidence after fix (Vitest output):

src/agents/subagent-registry.test.ts                   Tests  61 passed (61)
src/agents/subagent-registry-lifecycle.test.ts         Tests  30 passed (30)
task-registry.maintenance.issue-60299.test.ts          Tests  24 passed (24)
task-registry.test.ts                                  Tests  75 passed (75)

The six new #90444 cases cover: terminal run → subagent row marked lost; live run (no endedAt) → row retained; non-authoritative runtime → terminal-run check still works via SQLite snapshot; freshly killed task (within grace window) → marked lost without waiting for grace expiry; same-run CLI peer row → marked lost alongside the subagent row; maintenance-lost + late COMPLETE → succeeded with cleared error and correct cleanup window.

Observed result after fix: kill path writes deliveryStatus = not_applicable immediately; task-row status stays running until the next maintenance sweep (≤ 60 s) detects endedAt in the SQLite+memory snapshot and writes status = lost for both the subagent row and any CLI peer row; a late lifecycle COMPLETE then upgrades lost → succeeded.

What was not tested: live gateway kill with a concurrent lifecycle COMPLETE event arriving in the same sweep window.

Repro confirmation: the new #90444 maintenance tests fail on the pre-patch code and pass with the fix; the CLI peer row test fails before the task.runtime === "cli" extension and passes after; the lost → succeeded field test fails before the patch.error = undefined / patch.cleanupAfter = undefined normalization and passes after.

Risk / Mitigation

• Risk: Up to 60 s window between kill and task-row finalization. Mitigation: the window is bounded by TASK_SWEEP_INTERVAL_MS; the previous approach had no deadline at all (rows stuck permanently).
• Risk: Killed entry absent from the SQLite snapshot after gateway restart. Mitigation: markSubagentRunTerminated calls params.persist() before returning, writing the entry (with endedAt) to SQLite; the per-sweep getSubagentRunsSnapshotForRead call reads that persisted data, so getSubagentRunEndedAt returns the value in the first post-restart sweep.
• Risk: lost → succeeded opens a window for unintended task resurrection. Mitigation: updateTaskStateByRunId is scoped by runId; only a completeTaskRunByRunId call for the same runId can trigger this transition, and that call originates exclusively from the authoritative lifecycle COMPLETE handler.
• Risk: CLI peer row false-positive if a CLI task shares a sourceId with a non-killed terminal subagent run. Mitigation: getSubagentRunEndedAt returns endedAt for any terminal run (killed or completed). If the parent subagent completed normally, its own lifecycle event would have already transitioned the CLI peer row to a terminal state before maintenance runs; maintenance only sees the CLI row as running when the normal finalization path failed (the exact failure the issue reports).

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Agents / subagents
• Tasks / background jobs
• Diagnostics / maintenance

Linked Issue/PR

Fixes #90444