fix(whatsapp): patch Baileys QR auth handshake for sendUnifiedSession#74349
fix(whatsapp): patch Baileys QR auth handshake for sendUnifiedSession#74349Sathvik-1007 wants to merge 1 commit into
Conversation
WhatsApp servers now require sendUnifiedSession telemetry after pairing. Without it, QR scan shows 'Logging in...' then silently fails with no connection.update event. Patch ports the fix from upstream Baileys PR #2294: - bump bundled WA version 1027934701 � 1035194821 - add serverTimeOffsetMs state + updateServerTimeOffset() on pair success - emit sendUnifiedSession() after pair success and available presence - preserve existing media upload race fix and dispatcher guard Closes openclaw#46518
Greptile SummaryThis PR extends the existing Baileys pnpm patch to add the Confidence Score: 4/5Safe to merge with minor documentation clarification recommended — no correctness defects in the new logic. Both findings are P2: an undocumented WA client version bump (scope creep vs. stated boundary) and the potentially over-eager
Prompt To Fix All With AIThis is a comment left during a code review.
Path: patches/@[email protected]
Line: 9-10
Comment:
**Undocumented WA client version bump**
The WA protocol version is silently changed from `[2, 3000, 1027934701]` to `[2, 3000, 1035194821]`. The PR description states the scope boundary is "no Baileys version bump, no LID migration, no protobuf changes," yet this version number is what WA servers use to negotiate protocol capabilities and check for supported client builds. A version bump here could cause WA to enable or disable server-side features beyond the intended `sendUnifiedSession` handshake. If this bump is part of upstream PR #2294, it should be called out explicitly in the PR description and impact assessment.
How can I resolve this? If you propose a fix, please make it concise.
---
This is a comment left during a code review.
Path: patches/@[email protected]
Line: 43-45
Comment:
**`sendUnifiedSession` fires on every presence-available transition**
`sendUnifiedSession` is already called in both the `pair-success` and `CB:success` handlers on every (re)connect. Calling it again here on every `available` presence event means it fires repeatedly throughout a session — on every reconnect cycle, network blip, or manual presence refresh. If WA's server-side requirement is only to send it once per connection establishment, this creates unnecessary `ib` frames. If periodic sends are intentional, a comment explaining the expected cadence would clarify the intent for future maintainers.
How can I resolve this? If you propose a fix, please make it concise.Reviews (1): Last reviewed commit: "fix(whatsapp): patch Baileys QR auth han..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| -const version = [2, 3000, 1027934701]; | ||
| +const version = [2, 3000, 1035194821]; |
There was a problem hiding this comment.
The WA protocol version is silently changed from [2, 3000, 1027934701] to [2, 3000, 1035194821]. The PR description states the scope boundary is "no Baileys version bump, no LID migration, no protobuf changes," yet this version number is what WA servers use to negotiate protocol capabilities and check for supported client builds. A version bump here could cause WA to enable or disable server-side features beyond the intended sendUnifiedSession handshake. If this bump is part of upstream PR #2294, it should be called out explicitly in the PR description and impact assessment.
Prompt To Fix With AI
This is a comment left during a code review.
Path: patches/@[email protected]
Line: 9-10
Comment:
**Undocumented WA client version bump**
The WA protocol version is silently changed from `[2, 3000, 1027934701]` to `[2, 3000, 1035194821]`. The PR description states the scope boundary is "no Baileys version bump, no LID migration, no protobuf changes," yet this version number is what WA servers use to negotiate protocol capabilities and check for supported client builds. A version bump here could cause WA to enable or disable server-side features beyond the intended `sendUnifiedSession` handshake. If this bump is part of upstream PR #2294, it should be called out explicitly in the PR description and impact assessment.
How can I resolve this? If you propose a fix, please make it concise.There was a problem hiding this comment.
WA client version constant (lines 9-10): This is the internal WA protocol version constant, not the Baileys npm package version. The bump from 1027934701 → 1035194821 is part of upstream Baileys PR #2294 and is required — WA servers reject the old constant after the protocol change that added sendUnifiedSession. "No Baileys version bump" in the description refers to the npm package remaining at 7.0.0-rc.9.
| + if (type === 'available') { | ||
| + void sendUnifiedSession(); | ||
| + } |
There was a problem hiding this comment.
sendUnifiedSession fires on every presence-available transition
sendUnifiedSession is already called in both the pair-success and CB:success handlers on every (re)connect. Calling it again here on every available presence event means it fires repeatedly throughout a session — on every reconnect cycle, network blip, or manual presence refresh. If WA's server-side requirement is only to send it once per connection establishment, this creates unnecessary ib frames. If periodic sends are intentional, a comment explaining the expected cadence would clarify the intent for future maintainers.
Prompt To Fix With AI
This is a comment left during a code review.
Path: patches/@[email protected]
Line: 43-45
Comment:
**`sendUnifiedSession` fires on every presence-available transition**
`sendUnifiedSession` is already called in both the `pair-success` and `CB:success` handlers on every (re)connect. Calling it again here on every `available` presence event means it fires repeatedly throughout a session — on every reconnect cycle, network blip, or manual presence refresh. If WA's server-side requirement is only to send it once per connection establishment, this creates unnecessary `ib` frames. If periodic sends are intentional, a comment explaining the expected cadence would clarify the intent for future maintainers.
How can I resolve this? If you propose a fix, please make it concise.There was a problem hiding this comment.
sendUnifiedSession on presence-available (lines 43-45): Matches upstream exactly. WA expects periodic session telemetry, not one-shot on connect. The ib frame is tiny and fire-and-forget. Upstream wires it to presence-available because reconnect cycles re-announce presence — this keeps the session valid across network blips without requiring a full re-pair.
|
Thanks for the context here. I did a careful shell check against current Current main already implements the PR's central WhatsApp QR handshake fix by moving the WhatsApp plugin to So I’m closing this as already implemented rather than keeping a duplicate issue open. Review detailsBest possible solution: Keep the current-main Do we have a high-confidence way to reproduce the issue? Yes. The linked report gives concrete Docker/dashboard QR scan steps for the old Baileys rc9 path, and the source/dependency trail shows that path lacked upstream unified-session handling; I did not rerun live WhatsApp QR pairing. Is this the best way to solve the issue? Yes. Current main solves the same dependency-level gap by using Security review: Security review cleared: The PR changes only a dependency patch and lock hash; no new dependency source, lifecycle script, CI permission, secret handling, or command execution path was introduced. What I checked:
Likely related people:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 207fb9951d67; fix evidence: commit 85f9276624fc, main fix timestamp 2026-05-13T10:21:17Z. |
|
Codex review: needs maintainer review before merge. What this changes: This PR extends the local Baileys 7.0.0-rc.9 pnpm patch with unified-session/server-time telemetry hooks, updates the WhatsApp Web protocol version constant, preserves the media-upload hotfix, and refreshes the pnpm patch hash. Maintainer follow-up before merge: This is an active implementation PR touching patched dependency runtime/protocol behavior; the next action is maintainer review, upstream/version audit, changelog handling, and live QR proof, not an automated replacement branch. Review detailsBest possible solution: Land a maintainer-approved WhatsApp QR pairing fix in the WhatsApp plugin path, either by auditing this surgical Baileys patch or choosing a dependency upgrade, while preserving the existing media-upload hotfixes and adding changelog credit plus live QR pairing proof. Acceptance criteria:
What I checked:
Likely related people:
Remaining risk / open question:
Codex review notes: model gpt-5.5, reasoning high; reviewed against 8cf724a381a3. |
1 participant
Summary
WhatsApp QR received.sendUnifiedSessiontelemetry that WA servers now require after pairingChange Type (select all)
Scope (select all touched areas)
Linked Issue/PR
Root Cause (if applicable)
sendUnifiedSessiontelemetry after QR pair success and presence announcement. Baileys 7.0.0-rc.9 (bundled in OpenClaw) lacks this — upstream fixed in PR #2294.Regression Test Plan (if applicable)
connection.update→openstate within timeoutUser-visible / Behavior Changes
WhatsApp QR pairing works again. No config changes needed.
Diagram (if applicable)
N/A
Security Impact (required)
Repro + Verification
Environment
ghcr.io/openclaw/openclaw:latest(2026.3.13+)Steps
Expected
connection.update→ state transitions toopenActual (before fix)
WhatsApp QR received.then silenceEvidence
672/672 WhatsApp extension tests pass.
pnpm buildclean. Reporter's side-by-side test (issue comment) confirms Baileys-specific failure vs working wwebjs with same phone/network.Human Verification (required)
pnpm test:extension whatsapp(672 pass),pnpm buildclean,pnpm openclaw --versionrunsnode_modulesnuke + reinstall, existing media upload fix preserved, no export surface brokenReview Conversations
Compatibility / Migration
Risks and Mitigations