OpenClaw Fixes Two Silent Message-Loss Paths in Durable Ingress

OpenClaw has merged two corrections to its durable inbound-delivery path. One removes retention rules that could delete accepted WhatsApp messages before dispatch when more than 450 were waiting or a pending row was older than 30 days. The other releases deduplication state when an adopted queued run is dropped, allowing durable ingress to retry the message instead of rejecting that retry as a duplicate.

Both failures violated the same operator expectation: once the Gateway accepts a message into durable ingress, queue pressure, restart, reset, compaction or abort should not turn it into invisible loss.

Operator decision

Do not bulk-replay production messages blindly. Delayed commands may no longer be safe, and replay can duplicate side effects where original delivery status is uncertain.

Loss path one: retention ran before the first claim

WhatsApp used the shared ingress monitor with a 450-entry cap and a 30-day time-to-live for pending rows. Those limits are reasonable for completed history, but pending rows represent accepted, undelivered work.

The monitor applied retention before claiming the first row. A restart with 451 queued messages could therefore hard-delete the oldest accepted message before dispatch had a chance to process it. Age created the same category error: a message waiting longer than 30 days was treated as disposable history even though it had never been delivered.

PR #116179 removes those pending-work retention limits from WhatsApp’s monitor configuration. Interpretation: capacity control must not silently redefine accepted work as history. If a queue cannot grow safely, the system needs backpressure, admission failure or an explicit dead-letter outcome—not an invisible delete.

Loss path two: the retry looked like a duplicate

A message arriving while an agent was busy could be adopted into the session’s in-memory queue. If that queued run was then dropped before it started—through reset, compaction, abort, subagent cleanup or overflow eviction—durable ingress correctly released the message for another attempt.

The retry still failed because recent-message deduplication remembered the earlier queue adoption and rejected the newly released attempt. The message produced no reply and no transcript entry.

PR #115891 scopes that suppression to the queue-adoption lifecycle. Delivery remains protected from ordinary duplicate dispatch, while a run dropped before execution releases the relevant dedupe ownership so ingress retry can proceed. The follow-up commit also accounts for overflow-summary compaction cloning a queued run onto a new object.

Why existing health monitoring is not enough

A connected channel and an open durable queue do not prove that every accepted row will survive retention and dispatch. These bugs sit after admission: the provider can be connected, health can look normal, and the message can already exist locally before it disappears.

Operators need three separate signals:

1. provider receipt or source message ID;
2. durable-ingress admission and claim state; and
3. transcript or explicit delivery/dead-letter outcome.

A gap between the first two suggests admission trouble. A gap after admission points to retention, queue ownership, dispatch or deduplication.

Safe validation after upgrading

Use an isolated account or staging fixture with harmless unique markers:

1. record the exact package version or source SHA;
2. queue more than 450 markers while dispatch is paused, restart once, then account for every marker;
3. create a message behind an active run and drop the queued run using a controlled reset or abort path;
4. verify the released message is retried and appears once in the transcript;
5. confirm ordinary duplicate provider events still produce no duplicate action; and
6. reconcile queue, transcript and dead-letter counts before removing the fixture.

Do not use commands that write files, send messages or mutate external systems as test payloads. A harmless marker must remain harmless if it arrives late or twice.

Evidence and limits

OpenClaw Academy reviewed the official merged-PR and commit records collected from the OpenClaw repository. Search retrieval independently corroborated the dropped-run mechanism for PR #115891; direct page extraction was unavailable during this run. We did not reproduce either fault against a live WhatsApp account, and we do not assign a complete affected-version range because the evidence establishes the faulty paths and merged fixes, not every package that contains them.

Bottom line

Durability starts at acceptance but only counts if work remains accountable through dispatch. These fixes close two paths where OpenClaw could accept a message and still lose it without a visible terminal outcome. Operators with large WhatsApp backlogs or queue-heavy sessions should upgrade to a confirmed containing build and reconcile by message ID rather than trusting connection status alone.