fix(deps): patch baileys to restore WhatsApp device pairing (companion_reg_refresh) - #2727
Conversation
WhatsApp added a companion_reg_refresh stage to device registration (~2026-07-28). Baileys acks and discards it, so pair-success is never emitted and linking a new device is impossible. The handler is absent from rc13, rc14 and master, so no published release fixes it (WhiskeySockets/Baileys#2737, reproduced independently in whatsmeow). Uses the existing patches/ mechanism to vendor two upstream fixes until they are merged: - Baileys#2765: handle companion_reg_refresh (rotate adv secret and re-render the QR without consuming a ref) — restores pairing - Baileys#2602: guard link_code_companion_reg against the notification shape that lacks the crypto fields (Invalid buffer / 400) Also bumps baileys rc13 -> rc14 (latest published), which the patch targets. Verified on a real deployment: pairing works again and inbound messages flow end-to-end.
Reviewer's guide (collapsed on small PRs)Reviewer's GuideRestores WhatsApp device pairing by upgrading Baileys to rc14 and applying a version-pinned patch for the new companion_reg_refresh notification and malformed/variant link-code registration payloads. Reviewers should verify patch-package installation, lockfile consistency, and compatibility with both QR and pairing-code flows; the patch should be removed once an upstream Baileys release includes these fixes. Sequence diagram for restored WhatsApp device pairingsequenceDiagram
actor User
participant WhatsApp
participant PatchedBaileys
participant Evolution
User->>Evolution: Start QR pairing
Evolution->>PatchedBaileys: Create pairing session
PatchedBaileys-->>User: Display QR
User->>WhatsApp: Scan QR
WhatsApp->>PatchedBaileys: companion_reg_refresh
PatchedBaileys->>PatchedBaileys: Rotate adv secret
PatchedBaileys-->>User: Render refreshed QR
WhatsApp->>PatchedBaileys: Pairing confirmation
PatchedBaileys-->>Evolution: pair-success
Evolution-->>User: connection.update open
alt Pairing-code flow
User->>Evolution: requestPairingCode()
Evolution->>PatchedBaileys: requestPairingCode()
WhatsApp-->>PatchedBaileys: link_code_companion_reg
PatchedBaileys-->>Evolution: Pairing code or guarded response
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Hey - I've reviewed your changes and they look great!
Sourcery assessment
Needs a human reviewer. This changes the WhatsApp device-pairing authentication flow by rotating and persisting the advertising secret, then regenerating the QR code when the server retires the old secret. If the notification handling or QR refresh is wrong, legitimate pairing can fail or an existing pending pairing can become unusable; reverting the code does not restore any secret already rotated and persisted.
Problem
Linking a new WhatsApp device is currently impossible on Evolution — QR pairing never completes and the phone shows "couldn't link device / não foi possível conectar no momento".
The root cause is upstream and not an Evolution bug: around 2026-07-28 WhatsApp added a new stage to the companion-registration flow, sending
<notification type='companion_reg_refresh'>after the QR scan. Baileys acks it and discards it, sopair-successis never emitted and the QR ref pool drains. See WhiskeySockets/Baileys#2737 — reproduced independently in whatsmeow, which confirms it affects every open client.Because
companion_reg_refreshis absent from Baileys rc13, rc14 and master, no published Baileys release fixes this. The fix only exists as unmerged PRs.This is the umbrella issue for those reports (#2696, #2679 and others here).
What this PR does
Uses the
patches/mechanism that already exists ondevelop(postinstall: patch-package, currently holding only a README) to vendor the fix until upstream merges it.package.json/package-lock.json— bumpsbaileysfrom7.0.0-rc13to7.0.0-rc14(latest published).patches/baileys+7.0.0-rc14.patch(new) — applies two upstream fixes:companion_reg_refreshby rotating the adv secret and re-rendering the QR without consuming a ref. This is what restores pairing.link_code_companion_reg: WhatsApp sends it in two shapes, and the one without the crypto fields crashes withBoom('Invalid buffer', 400)(that's #2600, which also breaks the pairing-code flow).The patch touches only 4 files (
Socket/messages-recv.js,Socket/socket.js,Utils/companion-reg-client-utils.{js,d.ts}) — no source maps, no unrelated build noise — and applies cleanly against a vanillabaileys@7.0.0-rc14.Verification
Tested on a real deployment (Evolution v2.3.7 base + this patch, Docker):
connection.updatenever reachedopen;requestPairingCode()crashed withInvalid buffer.state=open, session stable, and a real inbound WhatsApp message was delivered through the webhook end-to-end.I also posted the standalone Docker recipe in the linked comment for anyone who needs it before this lands.
Notes for maintainers
7.0.0-rc13instead if you'd rather not bump the dependency in the same PR; the patch just needs regenerating against that version.Summary by Sourcery
Restore WhatsApp device and pairing-code support by updating Baileys and applying the required upstream fixes.
Bug Fixes:
Enhancements:
Build: