OpenClaw merged a high-priority recovery fix tonight: PR #127510 keeps queued replies alive during session watchdog repair.
The problem showed up when a user sent another message while OpenClaw was legitimately busy with long compaction or memory-flush work. In that state, users waiting for a reply could lose the active turn or get stuck because recovery treated queued work as if it had vanished.
This is a reliability story, but it is also a trust story. Agents that accept follow-up messages during slow maintenance need to preserve those messages across recovery, not make users guess whether their work is still alive.
The Watchdog Edge Case
OpenClaw's diagnostic watchdog exists to recover stale or stuck session work. Before this fix, the watchdog protected maintenance only when no messages were queued, and it checked that policy after the embedded-run-handle abort path.
That ordering created a bad interaction. A queued turn could make both real embedded handles and reply-only operations eligible for premature cancellation before the configured compaction safety deadline. Separately, recovery treated each released lane as empty even though lane reset preserves and pumps queued turns.
PR #127510 changes that recovery path. OpenClaw now uses the existing compaction-timeout-plus-settle-grace deadline before either abort path, and it preserves queued work for both aborted and released outcomes.
The production patch is small: net negative lines, with no configuration, protocol, dependency, database-schema, or public API changes.
What Users Get
The practical behavior is simple: active compaction and memory flushing can finish within the configured safety window even if a follow-up message arrives.
Queued replies remain visible to recovery and can continue instead of disappearing from diagnostic state. Overdue work is still reclaimed. Ordinary global-lane waits, stale runs, empty queues, and zero-backlog behavior remain unchanged.
That balance matters because watchdogs are easy to overcorrect. If a recovery system is too aggressive, it cancels healthy work. If it is too timid, stuck sessions stay stuck. This fix narrows the distinction between "slow but valid" and "actually stale" by reusing the existing safety deadline and preserving the queue evidence.
Why It Matters for Long-Running Agents
OpenClaw users increasingly rely on longer-running sessions: channel replies, background work, memory recall, compaction, coding tasks, and recurring automation. Those workflows often involve bursts of follow-up messages while a previous reply is still settling.
In that world, a queued reply is not an incidental detail. It is user intent waiting its turn.
The fix protects that intent across recovery by making queued work part of the watchdog's state model. If a lane is released or an operation is aborted, OpenClaw still remembers whether work was queued and can continue processing instead of silently forgetting it.
Validation
The PR includes strong regression coverage. Before the production fix, the focused owner-boundary command failed 11 regressions across phase, owner, abort mode, command-lane, reply-operation, and heartbeat queued-state cases. After the fix, 135 diagnostic and recovery tests passed.
Another 117 command-queue and reply-admission sibling tests passed, including coverage for actual queued preflight-compaction ownership. A related ClawHub tooling-test race was also made deterministic without changing production behavior, and 41 plugin assertion tests passed.
Focused core typechecking, type-aware lint, formatting, import-cycle checks, max-lines ratchets, assertion-safety ratchets, and an independent code review also passed.
Bottom Line
PR #127510 closes a sharp recovery edge case without changing public APIs. When OpenClaw is slow because it is doing legitimate maintenance, queued replies should remain queued, recoverable, and eventually processed.
That is exactly the kind of quiet reliability improvement that makes unattended agents feel less brittle.