fix(bot): re-warm pairing flag on post-pair-restart close
After a successful QR scan Baileys closes with status 515 and the session-manager schedules a reconnect via setTimeout(stop().then(start)). That cleanup stop emits a SECOND close event which arrived at our pair-handler listener with warmingUp already cleared (the first qr cleared it). The decision then resolved to 'treat-as-timeout', detaching the listener and pushing session.timeout to the UI right at the moment the user actually paired successfully — pairing then silently completed in the DB but the UI never got session.connected. Fix: re-arm pairingWarmingUp inside the post-pair-restart branch so the cleanup-stop's close is swallowed too. Cleared again by the following qr/open from the freshly-reopened socket, which then emits session.connected to the UI. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
7af7aa35d0
commit
d0db248460
@ -169,6 +169,15 @@ export async function handleStartPairing(accountId: string): Promise<void> {
|
||||
// session-manager will reopen it with the new credentials —
|
||||
// the next `open` event finishes the pairing. Keep the
|
||||
// listener attached and don't surface a timeout to the UI.
|
||||
//
|
||||
// Re-arm the warming-up flag: the session-manager schedules a
|
||||
// cleanup `stop().then(start())` to kick off the reconnect.
|
||||
// That stop emits another close event that lands on this
|
||||
// listener BEFORE the new open arrives — without warming-up,
|
||||
// we'd treat it as a timeout and detach right when the user
|
||||
// actually paired successfully. Cleared again on the next
|
||||
// qr / open from the freshly-reopened session.
|
||||
pairingWarmingUp.add(id);
|
||||
logger.info(
|
||||
{ accountId: id },
|
||||
"pair: restart-required close (post-pair reconnect) — keeping listener alive",
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user