Investigating subagent continuity across gateway restarts
I’m seeing intermittent orchestration issues when a subagent triggers a gateway restart.
What I expect
If a subagent causes a disruptive action (like openclaw gateway restart), I expect the system to recover after restart, reconcile in-flight runs, and continue/close them deterministically.
What I implemented
I enabled boot-md and added a startup reconcile contract in BOOT.md using workspace/memory/subagent-watch.json.
Current flow:
1. On subagent spawn, I track the run in subagent-watch.json (run metadata + next check timestamp).
2. BOOT hook runs on gateway:startup.
3. BOOT reconcile does:
• load/initialize subagent-watch.json
• call subagents(action="list", recentMinutes=1440) as source of truth
• prune stale runs
• normalize active runs
• enforce assertions:
• top-level shape is {meta, runs}
• meta.activeCount === runs.length
• no duplicate runId
• atomic write back
• write subagent-watch.error.json on assertion failure
Why this exists
A subagent that executes the restart can lose its own continuity, so that disruptive run itself may appear stuck/failed even when the gateway comes back healthy.
Because of that, I treat disruptive run status as non-authoritative and always run a fresh non-disruptive verify step after restart.
Current observed behavior
• Gateway returns healthy (RPC probe: ok)
• BOOT reconcile runs and cleans stale watch state
• But disruptive run bookkeeping can still look messy/stuck from an orchestration perspective unless explicitly cleaned and verified
Question to the community and @Krill 🦐
What is the recommended native pattern for this in OpenClaw?
• Is there an official “expected-disruptive” run type / resume semantics?
• Should restart-triggering runs always be force-closed and replaced by a post-restart verify run?
• Any known race conditions between startup hooks and subagent state tracking?
• Best practice for deterministic run lifecycle after gateway restarts?
What I expect
If a subagent causes a disruptive action (like openclaw gateway restart), I expect the system to recover after restart, reconcile in-flight runs, and continue/close them deterministically.
What I implemented
I enabled boot-md and added a startup reconcile contract in BOOT.md using workspace/memory/subagent-watch.json.
Current flow:
1. On subagent spawn, I track the run in subagent-watch.json (run metadata + next check timestamp).
2. BOOT hook runs on gateway:startup.
3. BOOT reconcile does:
• load/initialize subagent-watch.json
• call subagents(action="list", recentMinutes=1440) as source of truth
• prune stale runs
• normalize active runs
• enforce assertions:
• top-level shape is {meta, runs}
• meta.activeCount === runs.length
• no duplicate runId
• atomic write back
• write subagent-watch.error.json on assertion failure
Why this exists
A subagent that executes the restart can lose its own continuity, so that disruptive run itself may appear stuck/failed even when the gateway comes back healthy.
Because of that, I treat disruptive run status as non-authoritative and always run a fresh non-disruptive verify step after restart.
Current observed behavior
• Gateway returns healthy (RPC probe: ok)
• BOOT reconcile runs and cleans stale watch state
• But disruptive run bookkeeping can still look messy/stuck from an orchestration perspective unless explicitly cleaned and verified
Question to the community and @Krill 🦐
What is the recommended native pattern for this in OpenClaw?
• Is there an official “expected-disruptive” run type / resume semantics?
• Should restart-triggering runs always be force-closed and replaced by a post-restart verify run?
• Any known race conditions between startup hooks and subagent state tracking?
• Best practice for deterministic run lifecycle after gateway restarts?
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
131,281Members
Resources
Similar Threads
Was this page helpful?
