Summary

• monitorWebInbox() inside the while(true) reconnect loop was not wrapped in try-catch
• If the connection attempt itself failed (e.g. ECONNRESET during TLS handshake to web.whatsapp.com), the exception propagated out of the loop, permanently killing the WhatsApp channel — even with maxAttempts: 0 (unlimited retries)
• Wrap listener creation in try-catch so connection-phase errors enter the same backoff/retry path as post-connection closes

Root cause

The reconnect loop handles two phases differently:

Real-world failure sequence observed:

1. Status 428 disconnect → retry starts
2. Retry calls monitorWebInbox() → waitForWaConnection() → TLS handshake
3. ECONNRESET on web.whatsapp.com:443 → promise rejects
4. Exception propagates out of while(true) → channel exits permanently

Test plan

• pnpm build passes
• pnpm test passes (6492 passed, 4 pre-existing failures unrelated)
• Deployed to local Docker gateway, WhatsApp connects normally

🤖 Generated with Claude Code

Greptile Overview

Greptile Summary

This change wraps WhatsApp Web listener creation inside the reconnect while (true) loop with a try/catch, so connection-phase failures (e.g. errors thrown by monitorWebInbox() / waitForWaConnection()) flow through the same backoff/retry path as post-connection closes.

The logic fits the existing reconnect design (backoff via computeBackoff, status emission via tuning.statusSink, and disconnect events via enqueueSystemEvent).

Confidence Score: 3/5

• Mostly safe to merge, but repeated connection failures can now leak sockets during retries.
• The reconnect-loop try/catch is correct for preventing permanent shutdowns, but monitorWebInbox allocates a socket before awaiting connection and does not close it on connection-phase rejection; with the new retry behavior that can accumulate resources in real-world flaky-network scenarios.
• src/web/inbound/monitor.ts (connection setup cleanup path)

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