947fdeab3b
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