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:
yiekheng 2026-05-10 19:09:08 +08:00
parent 7af7aa35d0
commit d0db248460

View File

@ -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",