fix(whatsapp): retry reconnect loop on initial connection failure by luizlf · Pull Request #9727 · openclaw/openclaw

luizlf · 2026-02-05T16:15:39Z

Summary

Retry initial WhatsApp Web listener startup failures in monitorWebChannel using the existing reconnect backoff instead of exiting.
Update reconnect status/logging for startup failures and respect maxAttempts.
Add a regression test that simulates an initial ENOTFOUND and verifies the reconnect loop retries.

Why

DNS/network errors during the very first WhatsApp connection (for example ENOTFOUND web.whatsapp.com) previously escaped the reconnect loop, causing the gateway to stop. This change makes initial connection failures behave like later reconnects and fixes [Bug]: WhatsApp reconnect loop exits on initial connection failure (DNS/network errors) #13506.

Log Evidence

Original bug (2026-02-05 07:16:14 UTC, production OpenClaw 2026.2.3): reconnect loop did not engage; channel remained dead until manual restart at 13:06.

{"error":"Error: getaddrinfo ENOTFOUND web.whatsapp.com"},"WebSocket error"
path: "opt/homebrew/lib/node_modules/openclaw/dist/web/session.js:117"
time: "2026-02-05T07:16:14.679Z"

Fix working (2026-02-05 15:01:56 UTC, dev build with fix): new "will retry" log indicates the initial failure is captured and the reconnect loop continues.

{"error":"ENOTFOUND web.whatsapp.com","reconnectAttempts":0},"web reconnect: failed to establish initial connection; will retry"
path: "/Users/lsantos/Projects/openclaw/src/web/auto-reply/monitor.ts:214"
time: "2026-02-05T15:01:56.442Z"

Testing

pnpm vitest run --config vitest.unit.config.ts "src/web/auto-reply.reconnects" (1 test passed in 17ms)
New test: src/web/auto-reply.reconnects-after-initial-connection-failure.test.ts uses a mocked listenerFactory that throws ENOTFOUND on the first attempt, asserts a second attempt happens without propagating the error, then aborts and closes cleanly.
pnpm build && pnpm check && pnpm test

AI Assistance

AI-assisted: yes (Codex (gpt-5.2-codex xhigh) full-auto).
Collaboration notes:
- Claude (Opus 4.5) analyzed logs and identified the root cause in monitorWebChannel (the initial await listenerFactory() call lacked a try/catch).
- Codex CLI reviewed the root cause, implemented the fix and wrote the test.
- Claude reviewed the fix and confirmed it matched the root-cause analysis.
Original prompt to Codex: "Fix the WhatsApp DNS reconnect bug. The issue is in src/web/auto-reply/monitor.ts around line 192 - the await listenerFactory() call needs try/catch to handle initial connection failures and continue the retry loop with backoff."
Understanding confirmation: I understand this change catches listener startup errors, records the failure, increments reconnect attempts, waits with backoff, and retries until the max attempts is reached; the new test asserts a retry happens after an initial ENOTFOUND.

Greptile Overview

Greptile Summary

This PR updates the WhatsApp Web reconnect logic so that failures during the initial listener startup are handled by the same reconnect/backoff loop as later disconnects, rather than escaping and stopping the gateway. Concretely, monitorWebChannel now wraps the initial listenerFactory/monitorWebInbox startup in a try/catch, records the error in channel status, increments reconnectAttempts, applies maxAttempts, waits using the configured backoff, and retries.

It also adds a regression test that simulates a first-attempt DNS failure (ENOTFOUND) from the listener factory and asserts that the reconnect loop performs a second startup attempt without propagating the initial error, then aborts cleanly.

Confidence Score: 4/5

This PR is close to merge-ready; the runtime fix looks correct, but the new regression test is likely to be flaky in CI as written.
The reconnect-loop change is localized and follows the existing backoff/maxAttempts flow. The main concern is the test’s dependence on a hard 200ms wall-clock polling loop with real timers, which can intermittently fail under CI load despite correct behavior.
src/web/auto-reply.reconnects-after-initial-connection-failure.test.ts

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

greptile-apps

_{1 file reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

src/web/auto-reply.reconnects-after-initial-connection-failure.test.ts

When DNS or network errors occur during initial WhatsApp connection (e.g., ENOTFOUND web.whatsapp.com), the reconnect loop now catches the error and retries with backoff, instead of exiting entirely. Fixes openclaw#2198

luizlf · 2026-02-10T18:36:46Z

CI Failure Note

The failing check (checks-windows) is unrelated to this PR. The failure is in src/docker-setup.test.ts ("avoids associative arrays so the script remains Bash 3.2-compatible"), which fails on Windows because bash is not available (result.status is null instead of 0).

This test was introduced by commit 6731c6a1c ("fix(docker): support Bash 3.2 in docker-setup.sh") on main — it's a pre-existing issue on upstream.

All tests from this PR pass on all platforms, including the new src/web/auto-reply.reconnects-after-initial-connection-failure.test.ts.

luizlf · 2026-02-13T12:16:58Z

Fixes #13371

luizlf · 2026-02-16T22:47:13Z

Agree @nikolasdehor. Great job bringing more attention to this.
Thanks!
Hoping the maintainers see this soon.

…from PR openclaw#9727)

nikolasdehor

I previously reviewed and approved PR #14484 by @onthway, which was closed as a duplicate of this PR. Both address the same root cause — #13371 (WhatsApp permanent disconnect on DNS/timeout), which I've been tracking since it was filed.

Core fix comparison:

Both PRs take the same fundamental approach: wrap the listenerFactory/monitorWebInbox() call inside the reconnect while(true) loop with a try-catch, so connection-phase errors (DNS failures, TLS handshake errors, etc.) flow into the existing backoff/retry path instead of crashing the loop. This is the correct fix.

What #14484 had that this PR is missing:

The socket leak fix in src/web/inbound/monitor.ts. When waitForWaConnection(sock) throws, the already-created socket from createWaSocket() is never closed. #14484 addressed this with:

try {
  await waitForWaConnection(sock);
} catch (err) {
  try {
    sock.ws?.close();
  } catch {}
  throw err;
}

Without this, each failed connection retry accumulates a dangling socket/FD. Under sustained DNS/network failures with the reconnect loop now correctly retrying, this could mean dozens of leaked sockets before maxAttempts is reached (or unlimited leaks if maxAttempts: 0).

I flagged this in my earlier comment, and I think it should be included before merge. It's a 5-line change in a separate file so it won't conflict with anything here.

Minor observations on the catch block:

emitStatus() is called twice in succession (lines ~210 and ~213) — the first emit is immediately superseded by the second. Could consolidate to a single emit after all status fields are set.
The log level is error for the initial failure message. #14484 used warn which feels more appropriate since this is now a retryable condition, not a terminal error. Minor style point.

Summary: The core fix is solid and correct. I'd like to see the socket leak fix from #14484 folded in before this merges — otherwise we're solving the reconnect problem but introducing a resource leak under the exact conditions the fix enables (repeated connection failures). Happy to approve once that's added.

steipete · 2026-02-24T05:24:12Z

Closing as AI-assisted stale-fix triage.

Linked issue #13506 ("[Bug]: WhatsApp reconnect loop exits on initial connection failure (DNS/network errors)") is currently CLOSED and was closed on 2026-02-13T03:23:29Z with state reason NOT_PLANNED.
Given that issue state, this fix PR is no longer needed in the active queue and is being closed as stale.

If the underlying bug is still reproducible on current main, please reopen this PR (or open a new focused fix PR) and reference both #13506 and #9727 for fast re-triage.

steipete · 2026-02-24T05:24:13Z

Closed after AI-assisted stale-fix triage (closed issue duplicate/stale fix).

openclaw-barnacle bot added the channel: whatsapp-web Channel integration: whatsapp-web label Feb 5, 2026

luizlf mentioned this pull request Feb 5, 2026

[Bug]: WhatsApp gateway fails to reconnect after DNS resolution failure #2198

Closed

greptile-apps bot reviewed Feb 5, 2026

View reviewed changes

src/web/auto-reply.reconnects-after-initial-connection-failure.test.ts Outdated Show resolved Hide resolved

luizlf added 2 commits February 10, 2026 13:21

fix(whatsapp): retry reconnect loop on initial connection failure

439753d

When DNS or network errors occur during initial WhatsApp connection (e.g., ENOTFOUND web.whatsapp.com), the reconnect loop now catches the error and retries with backoff, instead of exiting entirely. Fixes openclaw#2198

test: stabilize reconnect retry test

465acbc

luizlf force-pushed the fix/whatsapp-dns-reconnect branch from 76011d5 to 465acbc Compare February 10, 2026 16:21

luizlf mentioned this pull request Feb 10, 2026

[Bug]: WhatsApp reconnect loop exits on initial connection failure (DNS/network errors) #13506

Closed

luizlf mentioned this pull request Feb 13, 2026

[Bug] WhatsApp channel exits permanently after DNS failure instead of retrying #13371

Open

thewilloftheshadow force-pushed the main branch from bfc1ccb to f92900f Compare February 15, 2026 18:46

This comment was marked as spam.

Sign in to view

onthway added a commit to onthway/openclaw that referenced this pull request Feb 17, 2026

test(whatsapp): add reconnect-after-initial-connection-failure test (…

85c0b18

…from PR openclaw#9727)

nikolasdehor reviewed Feb 19, 2026

View reviewed changes

steipete closed this Feb 24, 2026

Lucenx9 mentioned this pull request Feb 25, 2026

fix(whatsapp): catch connection-phase errors in reconnect loop (AI-assisted) #26760

Closed

19 tasks

mecampbellsoup mentioned this pull request Feb 26, 2026

Slack socket mode connection does not recover after transient DNS failure (same root cause as #13506) #27077

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(whatsapp): retry reconnect loop on initial connection failure#9727

fix(whatsapp): retry reconnect loop on initial connection failure#9727
luizlf wants to merge 2 commits intoopenclaw:mainfrom
luizlf:fix/whatsapp-dns-reconnect

luizlf commented Feb 5, 2026 •

edited

Loading

Uh oh!

greptile-apps bot left a comment

Uh oh!

Uh oh!

luizlf commented Feb 10, 2026

Uh oh!

luizlf commented Feb 13, 2026

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

luizlf commented Feb 16, 2026

Uh oh!

nikolasdehor left a comment

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

luizlf commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Log Evidence

Testing

AI Assistance

Greptile Overview

Greptile Summary

Confidence Score: 4/5

Uh oh!

greptile-apps bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

luizlf commented Feb 10, 2026

CI Failure Note

Uh oh!

luizlf commented Feb 13, 2026

Uh oh!

This comment was marked as spam.

This comment was marked as spam.

This comment was marked as spam.

luizlf commented Feb 16, 2026

Uh oh!

nikolasdehor left a comment

Choose a reason for hiding this comment

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

steipete commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

luizlf commented Feb 5, 2026 •

edited

Loading