openclaw - 💡(How to fix) Fix Subagent runs can be falsely marked failed/lost after clean gateway close or pending wait [1 comments, 2 participants]

Summary

Subagent lifecycle recovery can falsely mark a run as failed/lost when the gateway connection closes cleanly, agent.wait returns pending, or the in-memory run context is missing while the backing session is still running.

This showed up as repeated Mission Control/Workshop subagent failures such as:

• gateway closed (1000 normal closure): no close reason
• subagent run lost active execution context
• backing session missing

The underlying child work sometimes continued or produced useful output, but the registry/runtime marked the parent task as failed or lost.

Observed behavior

On OpenClaw 2026.4.26, with Gateway bound to loopback on macOS:

• Gateway: 127.0.0.1:18789
• Runtime: Mac mini LaunchAgent
• Subagent tasks launched from Mission Control / Workshop

Failure modes observed:

1. gateway closed (1000 normal closure) was treated as terminal instead of recoverable.
2. waitForSubagentCompletion() returned permanently when agent.wait returned pending, leaving no follow-up waiter attached.
3. The subagent sweeper marked a run as subagent run lost active execution context even when the backing session store still had status: "running".

Expected behavior

• Clean websocket close 1000 during gateway reconnect/restart windows should be treated as recoverable, similar to transport close / connection loss.
• A pending wait result should schedule a follow-up wait rather than dropping lifecycle supervision.
• If the sweeper loses in-memory run context but the backing session entry still says running, it should reattach/re-wait rather than terminally fail the run.

Local hotfix applied

I applied a local hotfix to the bundled dist as a temporary guard:

dist/run-wait-*.js

Add gateway closed (1000...) to recoverable wait errors:

const RECOVERABLE_AGENT_WAIT_ERROR_PATTERNS = [
  /gateway closed \(1000/i,
  /gateway closed \(1006/i,
  /transport close/i,
  ...
]

dist/subagent-registry-*.js

When agent.wait returns pending, schedule another wait:

if (wait.status === "pending") {
  log.info("subagent wait still pending; scheduling follow-up wait", {...})
  const scheduledEntry = entry
  setTimeout(() => {
    const current = params.runs.get(runId)
    if (!current || current !== scheduledEntry || typeof current.endedAt === "number") return
    waitForSubagentCompletion(runId, waitTimeoutMs, scheduledEntry)
  }, RECOVERABLE_WAIT_RETRY_DELAY_MS).unref?.()
  return
}

In the sweeper, if the backing session is still running, reattach instead of failing:

if (sessionEntry?.status === "running") {
  resumedRuns.delete(runId)
  resumeSubagentRun(runId)
  continue
}

Local verification

After applying the hotfix:

• node --check passed for the patched runtime files.
• Gateway restarted cleanly.
• A controlled subagent lifecycle smoke test completed successfully.
• Mission Control/Workshop tasks stopped failing with the previous lost-context pattern.

Suggested upstream fix

Implement the above behavior in source, with tests covering:

1. waitForAgentRun() treats gateway closed (1000...) as recoverable.
2. waitForSubagentCompletion() continues supervising after pending.
3. Sweeper reattaches when session store entry is still running even if in-memory run context is missing.
4. Sweeper still fails closed when the session entry is missing, terminal, stale, or drifted.

Why this matters

Without this, a clean gateway reconnect/restart or transient wait state can cause false failed/lost task records, noisy user-facing completion events, and stale recovery tasks in Mission Control.