Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

This is a refreshed report for #74424. I am closing the old issue only because it has gone stale in triage; the underlying gateway restart continuation contract still appears unresolved on current main.

A gateway tool action: "restart" call that includes continuationMessage can return success with coalesced: true while the continuation was never persisted or queued for post-restart delivery.

Current main status

Checked against current main at 7fbca96 on 2026-05-26.

The old issue still matches the current code shape:

• gateway.restart builds a restart sentinel payload with a continuation from continuationMessage.
• The sentinel is written only from the restart scheduler beforeEmit hook.
• scheduleGatewaySigusr1Restart() still has an already-emitted / unconsumed restart path that returns early with coalesced: true before a new caller hook can run.
• Startup only dispatches continuation work when the persisted sentinel contains payload.continuation.

So the tool can appear to accept the continuation while the continuation is not actually queued.

Steps to reproduce

1. Trigger a gateway restart from a config/plugin workflow, for example installing/enabling a plugin or updating plugins.entries.* under the default hybrid reload path.
2. While that restart is already scheduled or in-flight, call the gateway tool explicitly with an additional restart request that includes a continuation:

{
  "action": "restart",
  "reason": "Load newly installed plugin and channel account",
  "note": "Installed plugin and channel account; restarting gateway to load the plugin.",
  "continuationMessage": "Gateway restart completed. Continue checking whether the new plugin tools are visible; if available, invoke the expected readiness/account tool; otherwise report the missing tool surface."
}

3. Observe the tool response contains mode: "emit" and coalesced: true.
4. Wait for the gateway restart to complete.

Expected behavior

If the gateway restart tool accepts continuationMessage and returns ok, the continuation should be durably queued and delivered exactly once after restart, even when the restart request coalesces with an existing restart.

If OpenClaw cannot guarantee delivery in a coalesced path, the tool response should explicitly report that the continuation was not queued instead of returning a normal success shape.

Actual behavior

The gateway restart notification is delivered, but the continuation run is not triggered. The user sees a successful restart/config-patch notice, but no follow-up agent turn is created from the provided continuationMessage.

This can stall plugin installation, channel activation, or config-reload workflows after restart. The user has to manually send another message even though the tool response looked successful.

Prior evidence and discussion carried forward

Old issue: #74424

Prior ClawSweeper review kept #74424 open and summarized the bug as source-reproducible: with an emitted but unconsumed restart signal, gateway.restart with continuationMessage reaches the early coalesced return before beforeEmit can write the sentinel.

Important design point from the old review: a naive global rewrite of restart-sentinel.json can overwrite or misroute another session's continuation, so the fix needs a session/routing guard or an explicit non-queued result.

A prior comment by hclsys pointed at #73812 as likely covering this case, but #73812 is now closed unmerged. #74443 was another exact attempted fix and is also closed unmerged.

Related people mentioned by the old review included obviyus, VACInc, fuller-stack-dev, and steipete; this is context, not an ownership assignment.

Related PRs and issues

• fix(gateway): report unqueued restart continuations #83370 (fix(gateway): report unqueued restart continuations) is the current narrow active fix path and currently has green checks.
• fix(gateway/restart): write sentinel with continuationMessage on coalesced restart #74443 targeted this issue but was closed unmerged.
• Fix restart continuations after explicit restarts #73812 targeted adjacent restart-continuation behavior but was closed unmerged.
• RFC: Task Continuation Across Gateway Restarts (Checkpoint + Auto-Resume) #60864 tracks broader checkpoint/auto-resume semantics, but this report is narrower: an accepted one-shot continuationMessage should not be silently dropped.

Impact and severity

Affected: agent-driven plugin/channel setup flows and any workflow where an agent asks the gateway to restart with a one-shot continuation while another restart is already scheduled or in-flight.

Severity: High for these workflows. The user sees a successful restart notification but the promised follow-up work is silently lost.

Frequency: Intermittent/racy in general, but source-reproducible when action: "restart" with continuationMessage lands in the already-emitted restart window.

Suggested fix direction

Fix the restart tool/scheduler contract so an accepted continuation is queued exactly once for the correct pending restart, or so the tool response explicitly reports continuationQueued: false / equivalent when it cannot queue the continuation.