Skip to content

[Bug]: WhatsApp watchdog MESSAGE_TIMEOUT_MS (30min) not configurable — causes reconnect loops on low-traffic setups #53698

Description

@DevInvestor

Summary

The WhatsApp web monitor watchdog has a hardcoded MESSAGE_TIMEOUT_MS of 30 minutes (1800s). On low-traffic setups (e.g., DM-only with dmPolicy: allowlist), it's common to go hours without inbound messages. The watchdog treats this as a dead connection and force-closes it with status 499 ("watchdog-timeout"), triggering reconnect loops that eventually escalate to 440 (session conflict).

Root Cause

In channel.runtime-Cu2TxQlg.js (line ~2531):

const MESSAGE_TIMEOUT_MS = tuning.messageTimeoutMs ?? 1800 * 1e3;
const WATCHDOG_CHECK_MS = tuning.watchdogCheckMs ?? 60 * 1e3;

The WebMonitorTuning type defines messageTimeoutMs and watchdogCheckMs as optional, but no config path in openclaw.json exposes them. The tuning object is passed as {} from the gateway, so the 30-minute default always wins.

Environment

  • OS: Ubuntu 22.04 (DigitalOcean VPS)
  • OpenClaw: 2026.3.23-2
  • Node: v22.22.0
  • Config: channels.whatsapp.dmPolicy: allowlist, single allowed number

Steps to Reproduce

  1. Configure WhatsApp with dmPolicy: allowlist and a single allowed number
  2. Start gateway
  3. Wait ~30 minutes without sending any WhatsApp messages
  4. Observe watchdog firing every 60s, force-closing the connection with 499

Logs

12:47:14 [whatsapp] No messages received in 150m - restarting connection
12:47:15 [whatsapp] Web connection closed (status 499). Retry 1/12 in 2.19s… (status=499)
12:47:18 [whatsapp] Listening for personal WhatsApp inbound messages.
12:48:18 [whatsapp] No messages received in 151m - restarting connection
... (repeats every 60s)
12:53:41 [whatsapp] Web connection closed (status 440: session conflict)

Expected Behavior

Either:

  1. Make messageTimeoutMs configurable via channels.whatsapp.messageTimeoutMs (or plugins.entries.whatsapp.config.messageTimeoutMs)
  2. Disable the watchdog by default for allowlist DM-only setups where long idle periods are normal
  3. Increase the default significantly (e.g., 24h) — a 30-minute timeout is unreasonable for a personal assistant bot

Workaround

Gateway restart resets the lastInboundAt timer, temporarily clearing the loop. But it recurs after the next 30-minute idle window.

Related Issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions