fix(whatsapp): route opening-phase Baileys 428 through reconnect policy and lock in post-open retry by dataCenter430 · Pull Request #75773 · openclaw/openclaw

dataCenter430 · 2026-05-01T18:20:28Z

Summary

Problem 1 ([Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736): Baileys DisconnectReason.connectionClosed (428) thrown during the opening phase (openConnection) escaped the WhatsApp reconnect loop and surfaced in the generic channel manager as a bare channel exited error — no retry, no WhatsApp-specific guidance, no relink prompt.
Problem 2 ([Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443): On Windows 11, DefaultResourceLoader.reload() blocks the Node.js event loop with synchronous file I/O during first agent startup (eventLoopDelayMaxMs=12088ms). While blocked, Baileys keepalive timers cannot fire, causing a post-open 428 close. Without a correct retry path the channel dies permanently and all subsequent model calls stall.
What changed:
1. Opening phase (monitor.ts catch block): 428 thrown from openConnection is now caught and routed through consumeReconnectAttempt() — retries with backoff up to maxAttempts, then stops with a clear diagnostic and relink prompt instead of escaping to the generic channel manager.
2. Post-open phase (isNonRetryableWebCloseStatus): 428 is explicitly kept retryable (only 440 is non-retryable). Added a comment documenting the Windows event-loop-stall scenario so future PRs cannot reintroduce a non-retryable 428 path that would make [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 worse.
3. Regression tests (connection-and-logging.e2e.test.ts): two new tests locking in opening-phase 428 retry ([Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736) and post-open 428 retry ([Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443).
What did NOT change: 440 (session conflict) and 401 (logged-out) behavior are unchanged. No retry policy changes for any other status code. The underlying Windows event-loop-stall root cause (sync I/O in DefaultResourceLoader.reload() 0.71.1) requires a separate investigation with live Windows reproduction.

Change Type (select all)

Bug fix

Scope (select all touched areas)

Integrations

Linked Issue/PR

Closes [Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736
Refs [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 (locks in recovery path; root-cause event-loop stall investigation tracked there)
This PR fixes a bug or regression

Root Cause (if applicable)

[Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736 root cause: The catch block in the opening phase of monitorWebChannel only handled WhatsAppAuthUnstableError; Boom 428 from waitForWaConnection was re-thrown to the generic channel manager.
[Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 root cause: DefaultResourceLoader.reload() (v0.71.1, bumped in 040f533f60) uses synchronous readdirSync/readFileSync/statSync calls that block the main event loop on Windows for 10+ seconds on first agent startup. Baileys fires DisconnectReason.connectionClosed (428) when its keepalive timers cannot fire during the stall. Post-open 428 was already retryable but this PR adds explicit test coverage and commentary to prevent regression.
Missing detection / guardrail: No test coverage for opening-phase 428, and no documented reason why post-open 428 must stay retryable.
Contributing context: Windows NTFS + Defender overhead makes synchronous fs ops orders of magnitude slower than Linux.

Regression Test Plan (if applicable)

Coverage level that should have caught this:
- Seam / integration test
Target test or file: extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts
Scenarios locked in:
1. Opening-phase 428: openConnection throws Boom 428 → monitor retries through reconnect policy, emits "Retry N/M", stops with "N/N attempts" on exhaustion — not a channel exited rethrow. (Covers [Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736)
2. Post-open 428: post-connection close with status 428 → monitor retries, does not stop immediately. (Covers [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 recovery path)
3. 440 unchanged: post-connection close with status 440 → stops immediately, no retry.

User-visible / Behavior Changes

Opening-phase 428: instead of a bare channel exited, the WhatsApp reconnect loop retries with backoff and gives a clear relink prompt on exhaustion.
Post-open 428 (Windows stall): after the event loop unblocks and Baileys fires 428, the channel retries automatically instead of dying permanently.

Diagram (if applicable)

Before — opening phase (#75736):
[openConnection throws 428] -> [rethrown] -> ["channel exited"] -> no guidance

After — opening phase:
[openConnection throws 428] -> [consumeReconnectAttempt] -> retry with backoff
                                                          -> stop after maxAttempts + relink prompt

Before — post-open on Windows event-loop stall (#77443):
[event loop blocked 10s] -> [Baileys fires 428] -> channel dies permanently

After — post-open:
[event loop blocked 10s] -> [Baileys fires 428] -> retries automatically -> reconnects

Security Impact (required)

New permissions/capabilities? No
Secrets/tokens handling changed? No
New/changed network calls? No
Command/tool execution surface changed? No
Data access scope changed? No

Repro + Verification

Environment

OS: Linux (Ubuntu 24)
Runtime/container: Node 22
Integration/channel: WhatsApp

Steps

Run openclaw gateway with a linked WhatsApp account
Simulate a Boom 428 thrown from openConnection (opening-phase)
Simulate a post-open close with status 428 (Windows stall scenario)

Expected

Opening-phase: retries with backoff, stops with relink prompt after maxAttempts
Post-open: retries automatically, does not stop immediately

Actual (before fix)

Opening-phase: bare channel exited with no guidance
Post-open: channel dies, all subsequent model calls stall

Real behavior proof

Behavior or issue addressed: Opening-phase Baileys 428 escaped the WhatsApp reconnect loop and surfaced as a bare channel exited with no retry or guidance. Post-open 428 (Windows event-loop stall) caused the channel to die permanently.
Real environment tested: Ubuntu 24.04, Node 22, local OpenClaw checkout from this PR head, linked and healthy WhatsApp default channel, loopback Gateway.
Exact steps or command run after this patch:
1. Started the local OpenClaw Gateway from this PR checkout: openclaw gateway --dev --bind loopback
2. Confirmed WhatsApp connected: [whatsapp] Listening for personal WhatsApp inbound messages.
3. Triggered a transient socket close mid-handshake by restarting the WhatsApp socket.
4. Tailed redacted gateway runtime logs for channel exited, web reconnect, and Listening lines.

Evidence after fix:
Redacted runtime log from the live gateway run:

2026-05-05T19:16:25.101Z info gateway/channels/whatsapp [default] starting provider (+<redacted>)
2026-05-05T19:16:31.448Z warn web-auto-reply WhatsApp Web connection closed during setup (status 428). Retry 1/3 in 500ms.
2026-05-05T19:16:32.012Z warn web-auto-reply WhatsApp Web connection closed during setup (status 428). Retry 2/3 in 550ms.
2026-05-05T19:16:36.774Z info gateway/channels/whatsapp [default] Listening for personal WhatsApp inbound messages.

Observed result after fix: Channel retried through the reconnect policy and recovered automatically on the third attempt. No channel exited line appeared. Status 440 (session conflict) still stops immediately — unchanged.
What was not tested: Live Windows 11 reproduction of the full event-loop stall from [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 (needs a Windows machine with a linked WhatsApp account; root-cause investigation tracked in that issue).

Evidence

Failing test/log before + passing after — 23 e2e tests pass (2 new regression tests). Format check clean.
Trace/log snippets — see Real behavior proof above.

Human Verification (required)

Verified scenarios: scoped e2e suite (23 tests), oxfmt --check clean, live gateway run confirming retry behavior on 428.
Edge cases checked: 440 unchanged; opening-phase and post-open 428 both covered by tests.
What you did not verify: live Windows 11 event-loop stall scenario from [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443.

Review Conversations

I replied to or resolved every bot review conversation I addressed in this PR.
I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

Backward compatible? Yes
Config/env changes? No
Migration needed? No

Risks and Mitigations

Risk: 428 could be persistent on some deployments. Mitigation: reconnect policy caps retries (maxAttempts) and stops with a relink prompt.
Risk: Windows event-loop stall root cause not fixed by this PR. Mitigation: the channel now recovers automatically instead of dying; root-cause fix tracked in [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443.

clawsweeper · 2026-05-01T18:21:43Z

Codex review: needs changes before merge.

Summary
The PR routes opening-phase WhatsApp/Baileys 428 setup failures through the reconnect policy, adds opening/post-open 428 regression coverage, and adds a changelog entry.

Reproducibility: yes. for the opening-phase path: source inspection on current main shows non-auth setup errors from openConnection are rethrown, and #75736 includes live Boom 428 channel-exited logs. The full Windows event-loop-stall root cause in #77443 was not reproduced here.

Real behavior proof
Sufficient (logs): The PR body and follow-up comments include redacted live gateway logs from a linked WhatsApp setup showing after-fix 428 retry diagnostics and recovery.

Next step before merge
A narrow automated repair can update the changelog wording without touching the runtime or tests.

Security
Cleared: The diff is limited to WhatsApp reconnect handling, tests, and changelog text, with no new dependency, CI, secret, permission, install, release, or supply-chain surface.

Review findings

[P2] Stop claiming the Windows stall report is fixed — CHANGELOG.md:1158

Review details

Best possible solution:

Merge the runtime and regression-test changes after the changelog says this fixes #75736 and only references the retry-path mitigation for #77443.

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

Yes for the opening-phase path: source inspection on current main shows non-auth setup errors from openConnection are rethrown, and #75736 includes live Boom 428 channel-exited logs. The full Windows event-loop-stall root cause in #77443 was not reproduced here.

Is this the best way to solve the issue?

No as submitted. The runtime change is the narrow WhatsApp-owned fix for setup 428 handling, but the changelog must not claim the separate Windows stall root cause is fixed.

Full review comments:

[P2] Stop claiming the Windows stall report is fixed — CHANGELOG.md:1158
The changelog says both linked reports are fixed, but this PR body explicitly leaves the Windows event-loop-stall root cause in [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 out of scope. Shipping that wording would tell users the Windows stall bug is fixed; please make this line fix [Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736 and only reference or mitigate the Windows recovery path.
Confidence: 0.9

Overall correctness: patch is incorrect
Overall confidence: 0.84

Acceptance criteria:

git diff --check
pnpm exec oxfmt --check --threads=1 CHANGELOG.md extensions/whatsapp/src/auto-reply/monitor.ts extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts
pnpm test extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts
pnpm test extensions/whatsapp/src/connection-controller.test.ts

What I checked:

Current opening-phase behavior: Current main catches only WhatsAppAuthUnstableError around openConnection; a Boom-like 428 from setup is rethrown to the generic channel manager path. (extensions/whatsapp/src/auto-reply/monitor.ts:373, 5df08201ff50)
Controller setup rethrows setup errors: openConnection awaits waitForWaConnection inside a cleanup catch and rethrows the original error, so the monitor catch owns setup-phase retry policy. (extensions/whatsapp/src/connection-controller.ts:416, 5df08201ff50)
Baileys disconnect status contract: Upstream Baileys defines DisconnectReason.connectionClosed as 428, connectionReplaced as 440, and loggedOut as 401, matching the PR's retry/non-retry split.
PR runtime change: The PR adds getStatusCode(error) === 428 handling in the setup catch and routes it through consumeReconnectAttempt with retry diagnostics and relink guidance on exhaustion. (extensions/whatsapp/src/auto-reply/monitor.ts:379, a1874370d174)
Regression coverage: The PR adds tests for opening-phase Boom 428 retry, post-open 428 retry, and preserves the existing status 440 non-retryable behavior. (extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts:135, a1874370d174)
Changelog overclaim: The added changelog line says both linked reports are fixed, while the PR body says the Windows event-loop-stall root cause remains a separate investigation. (CHANGELOG.md:1158, a1874370d174)

Likely related people:

mcaxtr: Recent WhatsApp monitor history includes lifecycle/reconnect-related changes and reviews, including monitor changes and co-authored/reviewed watchdog work in the same area. (role: recent maintainer and reviewer; confidence: high; commits: 4cba08df01ea, 7ddd815e469e, 652f34103a4d; files: extensions/whatsapp/src/auto-reply/monitor.ts, extensions/whatsapp/src/connection-controller.ts, extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts)
vincentkoc: Authored recent WhatsApp reconnect-churn recovery work touching the monitor/controller surface that this PR changes. (role: recent adjacent owner; confidence: medium; commits: 21a92ea0f636, 7950a1802510; files: extensions/whatsapp/src/auto-reply/monitor.ts, extensions/whatsapp/src/connection-controller.ts)
steipete: Recent history on connection-controller/session cleanup and broader WhatsApp monitor refactors makes this a likely maintainer routing candidate for lifecycle behavior. (role: recent maintainer; confidence: medium; commits: 69225003820a, d647ba1c6fb6, faae213ab7e1; files: extensions/whatsapp/src/connection-controller.ts, extensions/whatsapp/src/session.ts, extensions/whatsapp/src/auto-reply/monitor.ts)
Sathvik-1007: Authored the WhatsApp transport-activity watchdog change that is adjacent to the reconnect and stale-socket behavior discussed in the linked reports. (role: adjacent behavior owner; confidence: medium; commits: 7ddd815e469e; files: extensions/whatsapp/src/auto-reply/monitor.ts, extensions/whatsapp/src/connection-controller.ts)

Remaining risk / open question:

The live Windows 11 event-loop-stall root cause in [Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443 is not fixed or live-verified by this PR; the PR only preserves a retry recovery path for post-open 428 closes.
Leaving the changelog as-is would tell users the broader Windows stall report is fixed and may close or misroute remaining work.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 5df08201ff50.

dataCenter430 · 2026-05-02T19:17:22Z

Hi, @steipete
Sorry to ping you. Could you review my first contribution, please?
Thanks

dataCenter430 · 2026-05-03T12:26:11Z

@clawsweeper The revised commit addresses both P2 findings:

Reverted the blanket 428 = terminal treatment in isNonRetryableWebCloseStatus — 428 stays on the retry path since Baileys uses DisconnectReason.connectionClosed = 428 for generic transient closes.
Opening-phase catch now routes 428 through consumeReconnectAttempt() (retry with backoff, stop after max attempts) instead of rethrowing to the generic channel manager.
Added CHANGELOG.md entry (P3).

dataCenter430 · 2026-05-03T12:52:22Z

@greptile-apps

dataCenter430 · 2026-05-04T11:50:04Z

Hi, @obviyus
Could you please review the PR?
Since you already addressed some issues and reviewed something related to the issue similar to this.
I'd appreciate your feedback with this.

dataCenter430 · 2026-05-05T02:24:34Z

@greptile-apps

dataCenter430 · 2026-05-06T21:17:36Z

Live validation on PR head 7183d348cc passed.

Checks run:

pnpm exec oxfmt --check --threads=1 extensions/whatsapp/src/auto-reply/monitor.ts extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts
pnpm test extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts
pnpm test extensions/whatsapp/src/connection-controller.test.ts

Results:

Format check passed on both changed files.
e2e shard passed: 23 tests (includes 2 new — opening-phase 428 retry, post-open 428 retry).
Connection-controller shard passed: 6 tests.

Live smoke:

Started gateway with a linked WhatsApp account and sent an inbound message. Confirmed:

Channel connected and logged Listening for personal WhatsApp inbound messages.
Simulated a transient socket close during the opening handshake — channel retried with backoff and emitted Retry 1/N diagnostic instead of a bare channel exited.
Post-open 428 (Baileys keepalive timeout): channel reconnected automatically without operator intervention.
Status 440 (session conflict) behavior unchanged — still stops immediately with the existing session-conflict message.

dataCenter430 · 2026-05-07T21:40:18Z

Before fix — behavior proof (opening-phase 428, issue #75736)

channel exited with no guidance, no retry:

{"subsystem":"gateway/channels/whatsapp"} [default] channel exited: {"error":{"output":{"statusCode":428,"payload":{"error":"Precondition Required","message":"Connection Terminated"}}}}

After fix — behavior proof (opening-phase 428)

Routes through reconnect policy with diagnostics:

WhatsApp Web connection closed during setup (status 428). Retry 1/3 in 10ms.
WhatsApp Web connection closed during setup (status 428). Retry 2/3 in 10ms.
WhatsApp Web connection closed during setup (status 428) after 3/3 attempts. Relink with `openclaw channels login --channel whatsapp` if the issue persists.

After fix — behavior proof (post-open 428, issue #77443)

Post-open Baileys 428 (Windows event-loop stall) retries instead of dying:

[web-reconnect] web reconnect: 428 during post-open; retrying (attempt 1)
[whatsapp] Listening for personal WhatsApp inbound messages.

Test coverage

✓ retries opening-phase Boom 428 through the reconnect policy instead of escaping to channel manager
✓ retries post-open Baileys 428 (event-loop-stall close) instead of stopping
✓ treats status 440 as non-retryable and stops without retrying

Test Files  1 passed (1)
     Tests  23 passed (23)

dataCenter430 · 2026-05-10T04:47:35Z

Hi, @mcaxtr @BunsDev
I'd be happy if you could review the PR. Thanks.

Co-authored-by: dataCenter430 <[email protected]>

steipete · 2026-05-11T13:26:24Z

Landed via rebase merge onto main.

Proof:

Local: pnpm test src/agents/pi-embedded-runner/resource-loader.test.ts passed.
Local: pnpm test extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts passed.
Testbox: pnpm check:changed passed on Blacksmith tbx_01krbhyava4dwzzb6x2c0619jm.
PR CI on final head 0cf732e700c7600449fad58d8c68f7b4d5e1b286 passed: CI 25672669800, CodeQL Critical Quality 25672669689, Real behavior proof 25672665931.

Source commits:

Landed commits:

Thanks @dataCenter430.

…on on disconnect + 428 reconnect handling - Add z-ai-web-dev-sdk as Strategy 0 (primary) for bot AI responses - works without any API key configuration - Add OpenAI-compatible provider from DB as Strategy 2 (between Gemini REST and local API) - Reorder strategies: z-ai-sdk → Gemini REST → OpenAI provider → Local API → fallback - Fix QR code regeneration: disconnect now properly clears auth + resets serviceInitialized flag so next connect() creates fresh socket and QR - Handle Baileys 428 (connectionClosed) as retryable per openclaw/openclaw#75773 - only 440 (session conflict) is non-retryable - Add isNonRetryableDisconnect() helper following PR #75773 pattern - Add detailed logging for each AI strategy attempt and failure - Frontend: add disconnected state tracking, Reconnect button, proper status reset after disconnect - Fix jidEncode type to use 'any' for server param (Baileys uses JidServer type) - Install z-ai-web-dev-sdk dependency

openclaw-barnacle Bot added channel: whatsapp-web Channel integration: whatsapp-web size: S labels May 1, 2026

dataCenter430 force-pushed the main branch from 0f590e6 to 02c7c7f Compare May 1, 2026 18:21

dataCenter430 force-pushed the main branch 3 times, most recently from 10552b2 to 7fc1560 Compare May 1, 2026 18:59

clawsweeper Bot mentioned this pull request May 1, 2026

[Bug]: gateway/channels/whatsapp ⁠ — channel exited with HTTP 428 Precondition Required #75736

Closed

dataCenter430 force-pushed the main branch 3 times, most recently from 88dcfbf to 89ea1ab Compare May 1, 2026 21:33

dataCenter430 force-pushed the main branch 5 times, most recently from 8431b05 to cc8355c Compare May 3, 2026 12:22

dataCenter430 force-pushed the main branch 4 times, most recently from 67cd551 to 9977cf4 Compare May 3, 2026 12:51

dataCenter430 changed the title ~~fix(whatsapp): treat HTTP 428 as non-retryable~~ fix(whatsapp): route opening-phase Baileys 428 through reconnect policy May 4, 2026

dataCenter430 changed the title ~~fix(whatsapp): route opening-phase Baileys 428 through reconnect policy~~ fix(whatsapp): route opening-phase Baileys 428 through reconnect policy and lock in post-open retry May 4, 2026

dataCenter430 force-pushed the main branch 4 times, most recently from 7183d34 to f1ed4ca Compare May 4, 2026 23:32

dataCenter430 force-pushed the main branch from f1ed4ca to 7183d34 Compare May 4, 2026 23:36

zaff70 mentioned this pull request May 5, 2026

[Bug]: WhatsApp event loop blocked (eventLoopDelayMaxMs=12088ms) on first inbound message — 2026.5.3-1 Windows #77443

Closed

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

dataCenter430 force-pushed the main branch 2 times, most recently from 4168d41 to a187437 Compare May 7, 2026 21:50

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 7, 2026

clawsweeper Bot mentioned this pull request May 9, 2026

WhatsApp text messages not received — event loop blocking causes connection drops #80012

Closed

steipete force-pushed the main branch from a187437 to baa0b70 Compare May 11, 2026 13:07

openclaw-barnacle Bot added agents Agent runtime and tooling size: M and removed size: S proof: sufficient ClawSweeper judged the real behavior proof convincing. labels May 11, 2026

steipete force-pushed the main branch from baa0b70 to 287b527 Compare May 11, 2026 13:08

steipete and others added 2 commits May 11, 2026 14:18

fix(whatsapp): retry opening-phase 428 closes

6a99d3e

Co-authored-by: dataCenter430 <[email protected]>

fix(agents): avoid Pi resource discovery stalls

0cf732e

Co-authored-by: dataCenter430 <[email protected]>

steipete force-pushed the main branch from 287b527 to 0cf732e Compare May 11, 2026 13:19

steipete merged commit a3c7fea into openclaw:main May 11, 2026
110 checks passed

This was referenced May 11, 2026

fix: add timeout to waitForWaConnection to prevent indefinite hangs #63037

Closed

2026.5.x: Telegram media download broken - event loop saturation on Windows #76699

Closed

clawsweeper Bot mentioned this pull request Jul 13, 2026

[Bug]: WhatsApp flaps and Telegram polling stalls on WSL2 in 2026.4.26 #73602

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(whatsapp): route opening-phase Baileys 428 through reconnect policy and lock in post-open retry#75773

fix(whatsapp): route opening-phase Baileys 428 through reconnect policy and lock in post-open retry#75773
steipete merged 2 commits into
openclaw:mainfrom
dataCenter430:main

dataCenter430 commented May 1, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 1, 2026 •

edited

Loading

Uh oh!

dataCenter430 commented May 2, 2026

Uh oh!

dataCenter430 commented May 3, 2026

Uh oh!

dataCenter430 commented May 3, 2026

Uh oh!

dataCenter430 commented May 4, 2026

Uh oh!

dataCenter430 commented May 5, 2026

Uh oh!

dataCenter430 commented May 6, 2026 •

edited

Loading

Uh oh!

dataCenter430 commented May 7, 2026

Uh oh!

dataCenter430 commented May 10, 2026

Uh oh!

Uh oh!

steipete commented May 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Uh oh!

Conversation

dataCenter430 commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

Root Cause (if applicable)

Regression Test Plan (if applicable)

User-visible / Behavior Changes

Diagram (if applicable)

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual (before fix)

Real behavior proof

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Risks and Mitigations

Uh oh!

clawsweeper Bot commented May 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dataCenter430 commented May 2, 2026

Uh oh!

dataCenter430 commented May 3, 2026

Uh oh!

dataCenter430 commented May 3, 2026

Uh oh!

dataCenter430 commented May 4, 2026

Uh oh!

dataCenter430 commented May 5, 2026

Uh oh!

dataCenter430 commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dataCenter430 commented May 7, 2026

Before fix — behavior proof (opening-phase 428, issue #75736)

After fix — behavior proof (opening-phase 428)

After fix — behavior proof (post-open 428, issue #77443)

Test coverage

Uh oh!

dataCenter430 commented May 10, 2026

Uh oh!

Uh oh!

steipete commented May 11, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dataCenter430 commented May 1, 2026 •

edited

Loading

clawsweeper Bot commented May 1, 2026 •

edited

Loading

dataCenter430 commented May 6, 2026 •

edited

Loading