fix: add timeout to waitForWaConnection to prevent indefinite hangs by mmcc9988 · Pull Request #63037 · openclaw/openclaw

mmcc9988 · 2026-04-08T08:34:10Z

Problem

waitForWaConnection listens for a Baileys connection.update event with either 'open' or 'close' status, but has no timeout. If Baileys fails to emit either event (e.g. due to network issues, DNS resolution failures, or internal errors), the promise hangs indefinitely, blocking the entire WhatsApp monitor loop from reconnecting.

Fix

Add a configurable timeoutMs parameter (default 60s) that:

Rejects the promise with a descriptive error if no connection state is received in time
Cleans up the event listener on timeout (prevents listener leaks)
Cleans up the timer on normal resolution (prevents dangling timers)

The change is backward-compatible — the timeout parameter is optional with a sensible default. Callers that pass 0 get the old behavior (wait forever).

Testing

All existing tests pass (the function is mocked in tests via vi.fn().mockResolvedValue(undefined))
The new timeout path follows the same cleanup pattern as the existing close path

greptile-apps · 2026-04-08T08:35:52Z

Greptile Summary

Adds a configurable timeoutMs parameter (default 60 s) to waitForWaConnection so the promise rejects with a descriptive error instead of hanging indefinitely when Baileys fails to emit a connection state. The cleanup helper correctly deregisters the event listener and cancels the timer on every exit path, and passing 0 preserves the old wait-forever behavior.

Confidence Score: 5/5

Safe to merge — the fix is correct, backward-compatible, and follows established patterns in the file.

All findings are P2 (a test for the new timeout path is missing but not blocking). The implementation is idempotent, handles cleanup on every exit path, and the timeoutMs=0 escape hatch correctly preserves old behavior.

No files require special attention.

Vulnerabilities

No security concerns identified.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/whatsapp/src/session.ts
Line: 232-238

Comment:
**Missing test coverage for the timeout path**

The existing tests in `session.test.ts` emit `"connection.update"` immediately, so they never exercise the new timeout branch. Adding a test case that calls `waitForWaConnection` with a short `timeoutMs` (e.g. 10) and lets the timer fire would prove the rejection error, listener cleanup, and `timeoutMs=0` "wait-forever" escape hatch all behave correctly.

```ts
it("rejects after timeout with no connection event", async () => {
  vi.useFakeTimers();
  const ev = new EventEmitter();
  const promise = waitForWaConnection(
    { ev } as unknown as ReturnType<typeof baileys.makeWASocket>,
    100,
  );
  vi.advanceTimersByTime(100);
  await expect(promise).rejects.toThrow("timed out after 100ms");
  vi.useRealTimers();
});
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: add timeout to waitForWaConnection ..." | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 006848c762

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1b4c6a9557

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 894a227a93

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

clawsweeper · 2026-04-27T01:33:51Z

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Keep this PR open: current main still has a source-reproducible unbounded WhatsApp connection wait, and the branch now preserves the no-timeout QR/login path while adding bounded waits at startup call sites. It is not merge-ready yet because this external PR still has only mocked/unit proof for a compatibility- and availability-sensitive live WhatsApp startup change.

Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

So I’m closing this here because the remaining work is already tracked in the canonical issue.

Review details

Best possible solution:

Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level. A socket/event emitter that never emits connection.update with open or close leaves current-main waitForWaConnection pending, and the monitor/controller await that promise during startup.

Is this the best way to solve the issue?

Yes for the code shape, but not merge-ready yet. The maintainable fix is a central wait helper with opt-in bounded startup call sites and preserved no-timeout login compatibility; the remaining gap is real behavior proof.

Security review:

Security review cleared: The diff changes WhatsApp runtime timeout handling and tests only; no concrete secret, dependency, workflow, package, or supply-chain expansion was found.

AGENTS.md: found and applied where relevant.

What I checked:

stale F-rated PR: PR was opened 2026-04-08T08:34:10Z, is older than 30 days, and the latest review rated it F.
proof blocker: real behavior proof is mock_only and proof tier is F, so this branch is not merge-ready without contributor follow-up.
no human follow-up: live comments and timeline hydrated by apply contain no non-automation activity after the ClawSweeper review.

Likely related people:

steipete: Current-main blame for the central waiter and monitor paths points to Peter Steinberger, and GitHub history shows recent WhatsApp/session and plugin-runtime maintenance in the same surface. (role: recent area contributor; confidence: medium; commits: 3f31b62cd41b, 27dde7a4d69b, 7b4d14f78683; files: extensions/whatsapp/src/session.ts, extensions/whatsapp/src/auto-reply/monitor.ts, src/plugins/runtime/runtime-web-channel-plugin.ts)
mcaxtr: GitHub file history shows recent work on WhatsApp 408 login timeout recovery and credential/session handling, and this PR’s latest branch-side repairs were also carried by this contributor. (role: recent WhatsApp connection lifecycle contributor; confidence: medium; commits: f613f32b227e, de743c5a543e, 194f0786d4e9; files: extensions/whatsapp/src/connection-controller.ts, extensions/whatsapp/src/session.ts)
vincentkoc: Recent current-main history includes WhatsApp reconnect and inbound recovery work adjacent to the setup/retry path changed here. (role: adjacent WhatsApp reconnect contributor; confidence: low; commits: 21a92ea0f636, e672b61417af; files: extensions/whatsapp/src/connection-controller.ts, extensions/whatsapp/src/auto-reply/monitor.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 6486fc1c0dfb.

clawsweeper · 2026-05-20T16:34:03Z

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?

The egg game starts only after the PR passes the real-behavior proof check.
Before that, no creature or rarity is rolled. The treat waits for real proof.
This is still just collectible flavor: proof affects review readiness, not creature quality.

If Baileys fails to emit a 'connection.update' event with either 'open' or 'close' status (e.g. due to network issues or internal errors), the waitForWaConnection promise hangs forever, blocking the entire monitor loop. Add a configurable timeout (default 60s) that rejects the promise and cleans up the event listener if no connection state is received in time. The timeout is backward-compatible as an optional parameter with a sensible default.

- Test that promise rejects with descriptive error after timeout - Test that event listener is cleaned up after timeout - Test that timer is cleared when connection opens before timeout

The 60s default broke the QR login flow in login-qr.ts, which calls waitForWaConnection without a timeout and expects to wait up to 3 minutes while the user scans. Change the default to 0 (wait forever, matching original behavior) and pass the 60s timeout explicitly at the monitor callsite where it's actually needed.

clawsweeper · 2026-06-04T22:56:39Z

ClawSweeper applied the proposed close for this PR.

Action: closed this PR.
Close reason: duplicate or superseded.
Evidence: durable ClawSweeper review.

mcaxtr · 2026-06-04T23:33:53Z

@clawsweeper re-review

clawsweeper · 2026-06-04T23:33:56Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

State: Complete
Detail: The targeted re-review finished, the durable review comment was updated, and the synced verdict was routed.
Run: https://github.com/openclaw/clawsweeper/actions/runs/26986003245
Updated: 2026-06-04T23:42:08.392Z

openclaw-barnacle Bot added channel: whatsapp-web Channel integration: whatsapp-web size: XS labels Apr 8, 2026

greptile-apps Bot reviewed Apr 8, 2026

View reviewed changes

Comment thread extensions/whatsapp/src/session.ts Outdated

chatgpt-codex-connector Bot reviewed Apr 8, 2026

View reviewed changes

Comment thread extensions/whatsapp/src/session.ts Outdated

openclaw-barnacle Bot added size: S and removed size: XS labels Apr 8, 2026

chatgpt-codex-connector Bot reviewed Apr 8, 2026

View reviewed changes

Comment thread extensions/whatsapp/src/session.ts Outdated

mmcc9988 force-pushed the fix/whatsapp-connection-timeout branch from 220e0ea to 894a227 Compare April 8, 2026 16:56

chatgpt-codex-connector Bot reviewed Apr 8, 2026

View reviewed changes

Comment thread extensions/whatsapp/src/inbound/monitor.ts Outdated

clawsweeper Bot mentioned this pull request May 15, 2026

WhatsApp WebSocket ETIMEDOUT on connection after login #61788

Closed

openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 19, 2026

clawsweeper Bot added the merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. label May 21, 2026

mcaxtr self-assigned this Jun 4, 2026

MMMMSSSS8899 and others added 6 commits June 4, 2026 19:18

test: add coverage for waitForWaConnection timeout path

e0c803b

- Test that promise rejects with descriptive error after timeout - Test that event listener is cleaned up after timeout - Test that timer is cleared when connection opens before timeout

fix: bound whatsapp connection startup waits

d6e1673

fix: align web channel wait contract

0ac1e09

fix: retry whatsapp setup timeouts

7c2437c

mcaxtr force-pushed the fix/whatsapp-connection-timeout branch from 894a227 to 7c2437c Compare June 4, 2026 22:47

openclaw-barnacle Bot added size: M and removed size: S labels Jun 4, 2026