An agent system can have healthy underlying workflows but lose its notifications when low-value transport chatter fills the same durable queue. The reported WhatsApp connection watchdog produced reconnect events on quiet accounts; the main session did not drain quickly, and task or cron updates competed for the same limited capacity. This is a liveness and…
Inspect the ClaimsCase · DiggingBeagle record
OpenClaw WhatsApp reconnect notices can crowd out useful agent task events
A reporter documents repeated WhatsApp connection-state events consuming a bounded agent queue so that task completion and scheduled events may not reach the model.
Scope
The frequency and losses were reported for one environment; no upstream corrected release was confirmed.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade D
- AI role
- AGAINST AI
Basis and provenance
The pinned Claim and its primary disclosure support the described controlled result, but do not establish a population-wide rate or calibrated impact. The only available supporting evidence is the reporter's or advisory author's own account; independent reproduction has not been shown. Impact remains unbanded because no calibrated impact rubric for this particular evidence is established.
Assessed Nov 2, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-2026-NOV02-OPENCLAW-WHATSAPP-QUEUE-A · OpenClaw issue 190640: WhatsApp reconnect notices fill main-session queue
At a glance
Queue capacity should prioritize outcome receipts over repeated transport noise, with durable acknowledgments and explicit drop accounting.
Read the implicationsThe frequency and losses were reported for one environment; no upstream corrected release was confirmed. Which task notifications were never delivered, as distinct from delayed or superseded reconnect notices, has not been independently reconstructed.
Limits and uncertaintyFull account
An agent system can have healthy underlying workflows but lose its notifications when low-value transport chatter fills the same durable queue. The reported WhatsApp connection watchdog produced reconnect events on quiet accounts; the main session did not drain quickly, and task or cron updates competed for the same limited capacity. This is a liveness and observability problem in a specific configuration, not proof that all WhatsApp bot sessions drop data.
Reconnect notices are low-value operational events, yet in the described setup they share a bounded twenty-entry queue with higher-value task and cron completion signals. Repeated connection churn can fill the queue while the main session is not draining it, turning a healthy-looking messaging integration into lost delivery receipts. The issue contains one deployment's logs rather than a prevalence survey. A repair should not merely increase the queue size: it needs separate lanes or coalescing for duplicate connection status, plus persistence and explicit delivery status for consequential task outcomes.
Mechanism and trust boundary
- 01
Transport emits repeated status events
A watchdog reconnect produces multiple low-priority notices.
Boundary: Chat connection state into agent event queue
- 02
Bounded queue becomes saturated
Status messages occupy limited slots while the agent is not consuming them.
Boundary: Nonessential events into shared capacity
- 03
Task notifications are dropped
Later job completions or cron signals cannot be enqueued in the reported case.
Boundary: Queue exhaustion into lost automation evidence
Claims & evidence
CLM-2026-NOV02-OPENCLAW-WHATSAPP-QUEUE-AThe OpenClaw issue reports a main-session event queue with capacity twenty being filled by repetitive connection notices, with 186 queue-full errors in the observed 12-day environment.supported
Basis: reported finding
- supportsOpenClaw issue 190640: WhatsApp reconnect notices fill main-session queueprimary disclosure
Issue 190640, 20-entry queue limit and reconnect log observations
Implications
Queue capacity should prioritize outcome receipts over repeated transport noise, with durable acknowledgments and explicit drop accounting.
Controls and mitigations
- Coalesce repeated status notifications, reserve capacity for actionable events and reconcile job results from a persistent outbox after recovery.
- Deduplicate status flaps, reserve capacity for task completions and persist acknowledged delivery IDs so a restart can replay only missing results.
Unknowns and contradictions
- The frequency and losses were reported for one environment; no upstream corrected release was confirmed.
- Which task notifications were never delivered, as distinct from delayed or superseded reconnect notices, has not been independently reconstructed.
Sources and citation
Material revision history
- Nov 2, 2026 · Canonical change recorded · new in release · revision 214