PR #75773: fix(whatsapp): treat HTTP 428 as non-retryable

• Repository: openclaw/openclaw
• Author: dataCenter430
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/75773

Description (problem / solution / changelog)

Summary

• Problem: After upgrading to 2026.4.29, a WhatsApp 428 "Precondition Required / Connection Terminated" thrown during the Baileys handshake (opening phase) escaped the WhatsApp reconnect loop entirely and landed in the generic channel manager as a bare channel exited error — no relink guidance, no clean stop.
• Why it matters: Operators saw recurring channel exited: statusCode 428 at ~04:00 UTC (token rotation window) with no actionable message. The transport-activity watchdog added in 4.29 (7ddd815e46) compounded this by forcing extra reconnects on transport silence.
• What changed: Two fixes at two levels:
  1. Opening phase (monitor.ts catch block): 428 thrown from openConnection is now caught and handled as a terminal non-retryable stop with a clear relink error, instead of being re-thrown to the generic channel manager.
  2. Post-open phase (isNonRetryableWebCloseStatus): 428 is added alongside 440 so a post-open Baileys 428 close also stops the monitor cleanly without spinning through the retry loop.
• What did NOT change: 440 (session conflict) and 401 (logged-out) behavior are unchanged. No retry policy changes for any other status code.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Integrations

Linked Issue/PR

• Closes #75736
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: The catch block in monitorWebChannel only handled WhatsAppAuthUnstableError; all other errors from openConnection (including Boom 428 from waitForWaConnection) were re-thrown to the generic channel manager. isNonRetryableWebCloseStatus also only listed 440, so a post-open 428 looped through retries until exhaustion.
• Missing detection / guardrail: No test coverage for 428 as a terminal status in either the opening or post-open path.
• Contributing context: The transport-activity watchdog added in 4.29 (7ddd815e46) made the failure surface as a visible regression.

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
• Scenario the test should lock in:
  1. Opening phase: openConnection throws Boom 428 → channel stops immediately, no retry, correct error message.
  2. Post-open phase: close with status 428 → channel stops immediately, no retry, correct error message.
• Why this is the smallest reliable guardrail: both tests mirror the existing 440 pattern end-to-end through monitorWebChannel.
• Existing test that already covers this: none for 428 before this PR.

User-visible / Behavior Changes

On HTTP 428 from WhatsApp (either during handshake or after connection opens): channel stops immediately with a clear session-expiry error and relink instructions, instead of looping or showing a generic channel exited error.

Diagram (if applicable)

Before (opening phase):
[waitForWaConnection throws 428] -> [rethrown] -> [generic channel manager exit] -> [generic restart loop]

Before (post-open phase):
[Baileys close 428] -> [retry loop x N] -> ["max attempts reached"] -> [stop]

After (both phases):
[428] -> [monitor: "session expired" + relink prompt] -> [clean stop]

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: Ubuntu 24
• Runtime/container: Node 22
• Integration/channel: WhatsApp (2026.4.29)

Steps

1. Run openclaw gateway with a WhatsApp account linked
2. Simulate a Boom 428 from Baileys during socket opening
3. Observe channel exits cleanly with relink prompt

Expected

• Channel stops on first 428 with session-expiry error and relink instructions

Actual (before fix)

• Opening-phase 428: generic channel exited with no guidance
• Post-open 428: silent retry loop until max attempts

Evidence

• Failing test/log before + passing after — two new tests pass; all 23 e2e tests and all 5 connection-controller tests pass. Format check clean.

Human Verification (required)

• Verified scenarios: scoped e2e suite (23 tests), connection-controller suite (5 tests), oxfmt --check — all clean.
• Edge cases checked: 440 behavior unchanged; 401 logged-out behavior unchanged.
• What you did not verify: live WhatsApp backend producing an actual 428 at token rotation time.

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 transient on some deployments. Mitigation: WhatsApp's 428 "Connection Terminated" is a session-level rejection requiring re-auth, matching how 440 is already treated.

Changed files

• extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts (modified, +83/-0)
• extensions/whatsapp/src/auto-reply/monitor.ts (modified, +40/-3)