* fix(whatsapp): resolve abortPromise when stop signal already fired
waitForClose() races on abortPromise, but a pre-aborted gateway stop
signal never settled that promise because the abort listener was skipped.
Resolve abortPromise immediately when abortSignal.aborted is already true.
Co-authored-by: Cursor <cursoragent@cursor.com>
* fix(whatsapp): resolve tsgo TS18048 and test mock in pre-aborted abortPromise fix
- Extract params.abortSignal to local const so tsgo can narrow the type
through else-if control flow, fixing TS18048: possibly undefined
- Remove setupAbortController/ownerAcquireAbortController.abort() from
the constructor's pre-aborted branch so openConnection() still works
when the stop signal was already fired at construction time
- Use createSocketWithTransportEmitter() mock in the new test so
shutdown() cleanup has sock.end() and ws.removeListener() available
* fix(whatsapp): preserve pre-aborted setup cancellation
* fix(whatsapp): unify connection abort handling
---------
Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(whatsapp): preserve auth on passive terminal stops
* fix(whatsapp): recover stale web auth during relink
* fix(gateway): defer channel stop until qr takeover
* fix: add timeout to waitForWaConnection to prevent indefinite hangs
If Baileys fails to emit a 'connection.update' event with either 'open'
or 'close' status (e.g. due to network issues or internal errors), the
waitForWaConnection promise hangs forever, blocking the entire monitor
loop.
Add a configurable timeout (default 60s) that rejects the promise and
cleans up the event listener if no connection state is received in time.
The timeout is backward-compatible as an optional parameter with a
sensible default.
* test: add coverage for waitForWaConnection timeout path
- Test that promise rejects with descriptive error after timeout
- Test that event listener is cleaned up after timeout
- Test that timer is cleared when connection opens before timeout
* fix: default timeoutMs to 0 to preserve QR login behavior
The 60s default broke the QR login flow in login-qr.ts, which calls
waitForWaConnection without a timeout and expects to wait up to 3 minutes
while the user scans. Change the default to 0 (wait forever, matching
original behavior) and pass the 60s timeout explicitly at the monitor
callsite where it's actually needed.
* fix: bound whatsapp connection startup waits
* fix: align web channel wait contract
* fix: retry whatsapp setup timeouts
* fix: satisfy whatsapp status lint
* fix: preserve whatsapp wait compatibility
---------
Co-authored-by: MMMMSSSS8899 <praelovk@gmail.com>
* WhatsApp: harden auth persistence and backup recovery
* WhatsApp: model unstable auth state across runtime and setup
* WhatsApp: recover login and monitor startup from unstable auth
* Channels: surface auth stabilizing in status and health
* Gateway protocol: add channels.start surface
* Gateway: reconcile local channel runtime after CLI login
* Channels UI: reflect recovered login start state
* Changelog: note WhatsApp auth stabilization
* Gateway: fix lint in call test
Marcus Castro