fix(whatsapp): guard bridge reconnect against hangs and unhandled rejections - #77337
Merged
kshitijk4poor merged 1 commit intoAug 3, 2026
Conversation
…ections startSocket() awaits useMultiFileAuthState() and fetchLatestBaileysVersion() before it creates a socket or registers event handlers, and the close handler re-entered it via a bare setTimeout(startSocket, ...). That leaves two unrecoverable failure modes on a reconnect: - a rejection is an unhandled promise rejection (fatal on modern Node) - a hang leaves the bridge permanently disconnected with nothing left to retry, while its HTTP server keeps answering 503 to the gateway The second mode was observed in the field: fetchLatestBaileysVersion() is a plain fetch to raw.githubusercontent.com with no AbortSignal, and after a stream:error 503 disconnect the bridge logged 'Reconnecting in 3s...' once and then sat silent and disconnected for 27+ hours until manually restarted. Fix, as two pure helpers in bridge_helpers.js (keeping bridge.js side-effect free to test): - createReconnectScheduler(): every (re)connect entry point now catches a failed startSocket() and reschedules it instead of dying or going silent - createVersionResolver(): bounds the version fetch with a 15s timeout and falls back to the last known-good version (or the Baileys default before first success) instead of pending forever
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Guards the WhatsApp bridge reconnect path against two unrecoverable failure modes that leave the bridge permanently disconnected while its Express server keeps answering 503 to the gateway.
Root cause
startSocket()awaitsfetchLatestBaileysVersion()(a plainfetch()toraw.githubusercontent.comwith no AbortSignal) before creating a socket or registering event handlers. The close handler re-entered it via a baresetTimeout(startSocket, ...). On reconnect:Observed in the field: bridge wedged 27+ hours after a
stream:error503, loggingReconnecting in 3s...once then going silent.Changes
bridge_helpers.js— two pure factory functions (keeping bridge.js side-effect-free per convention):createReconnectScheduler(startFn)— catches failedstartSocket()and reschedules (5s) instead of dying or going silentcreateVersionResolver(fetchFn)— bounds version fetch with 15s timeout, falls back to last known-good version or Baileys library defaultbridge.js— routes close-handler reconnect and gateway-mode initial connect through the scheduler; resolves WA version through the bounded resolverbridge.reconnect.test.mjs— 6 regression tests: retry-after-rejection, stop-after-success, sync-throw containment, timeout fallback to default, cached-version fallback, timer cleanupCredit
Cherry-picked from #77270 by @ATran28 (at828@proton.me). Authorship preserved via rebase-merge.
Closes #77268