Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: Expose WhatsApp web message watchdog timeout as config [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63925•Fetched 2026-04-10 03:41:39
View on GitHub
Comments
2
Participants
2
Timeline
4
Reactions
0
Author
oromeisoromeis
Participants
ArtyomkunArtyomkunoromeisoromeis
Timeline (top)
commented ×2cross-referenced ×1labeled ×1

Root Cause

In practice, this creates a maintenance problem for setups where a longer timeout is desirable, because:

Fix Action

Fix / Workaround

agents.defaults.heartbeat.every is configurable, but is not the same thing web.heartbeatSeconds and web.reconnect.* are configurable, but do not expose this watchdog timeout the only workaround today is patching compiled dist/login-*.js files after updates

PR fix notes

PR #63939: Add web.messageTimeoutMs for WhatsApp watchdog

Description (problem / solution / changelog)

Summary

Adds a small, backward-compatible config option for the WhatsApp web watchdog timeout.

This exposes web.messageTimeoutMs so deployments that need a longer watchdog window can configure it without carrying a local patch.

Closes #63925.

What changed

  • added web.messageTimeoutMs to config types and schema
  • added resolveMessageTimeoutMs(cfg, overrideMs?)
  • updated the WhatsApp web monitor to use config-aware timeout resolution
  • kept the default behavior unchanged at 30 minutes
  • documented the new field in the configuration reference and WhatsApp docs
  • added test coverage for default and override behavior

Why

Right now the watchdog timeout is effectively hard-coded. That makes it awkward to tune for quieter or longer-lived sessions, and local patches get overwritten on update.

This change keeps the existing default while making the timeout configurable in a narrow, low-risk way.

Testing

AI-assisted PR.

Tested locally:

  • pnpm test:extension whatsapp ✅
  • pnpm check ✅

Notes

  • default remains 30 * 60 * 1000
  • config field is optional
  • tuning overrides still take precedence in test-oriented paths

Changed files

  • docs/.generated/config-baseline.sha256 (modified, +3/-3)
  • docs/channels/whatsapp.md (modified, +1/-1)
  • docs/gateway/configuration-reference.md (modified, +1/-0)
  • extensions/whatsapp/src/auto-reply/monitor.ts (modified, +10/-4)
  • extensions/whatsapp/src/reconnect.test.ts (modified, +10/-0)
  • extensions/whatsapp/src/reconnect.ts (modified, +9/-0)
  • src/config/schema.base.generated.ts (modified, +13/-0)
  • src/config/schema.help.ts (modified, +2/-0)
  • src/config/schema.labels.ts (modified, +1/-0)
  • src/config/types.base.ts (modified, +1/-0)
  • src/config/zod-schema.ts (modified, +1/-0)
RAW_BUFFERClick to expand / collapse

Summary

Problem

OpenClaw's WhatsApp web runtime currently appears to have a hardcoded inbound-message watchdog timeout:

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

### Problem to solve

In practice, this creates a maintenance problem for setups where a longer timeout is desirable, because:

agents.defaults.heartbeat.every is configurable, but is not the same thing
web.heartbeatSeconds and web.reconnect.* are configurable, but do not expose this watchdog timeout
the only workaround today is patching compiled dist/login-*.js files after updates


### Proposed solution

Please expose this watchdog timeout via normal config, for example one of:

    web.messageTimeoutMs
    channels.whatsapp.web.messageTimeoutMs

or another officially supported field


### Alternatives considered

_No response_

### Impact

This would make the setting:

update-safe
reproducible
supportable
easier to document


### Evidence/examples

_No response_

### Additional information

_No response_

extent analysis

TL;DR

Exposing the watchdog timeout via a configurable field, such as web.messageTimeoutMs or channels.whatsapp.web.messageTimeoutMs, is likely the most straightforward fix.

Guidance

  • Identify the current hardcoded value of MESSAGE_TIMEOUT_MS and consider the desired timeout value for the specific setup.
  • Evaluate the proposed solution of adding a configurable field, such as web.messageTimeoutMs, to the existing configuration options.
  • Assess the impact of making this change on the overall system, including update safety, reproducibility, and supportability.
  • Consider the alternatives to patching compiled files, such as modifying the source code or using a different configuration approach.

Example

No code example is provided, as the issue focuses on configuration changes rather than code modifications.

Notes

The proposed solution aims to make the setting update-safe, reproducible, and supportable, which are essential considerations for maintaining a reliable system.

Recommendation

Apply workaround: Expose the watchdog timeout via a configurable field, as this approach addresses the maintenance problem and provides a more flexible solution.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#API rate limit#retriever error#indexing error#inference speed#output truncation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING