tai/research/whatsapp-automation/github-rich627-whatsapp-claude-plugin-pull-45.md

Rich627 whatsapp-claude-plugin PR 45: contact sync on new links (peer stanza classification)

Metadata

Field	Value
Institute	Molodetz Institute — Research & Retrieval Division
Subject	whatsapp-automation
Document type	Source Dossier
Tier	1
Source title	Fix contact sync on new links, name tags and group-member retention (0.27.1) (PR 45)
Source URL	https://github.com/Rich627/whatsapp-claude-plugin/pull/45
Source publisher / author	Kaushik
Source type	repository
Source date (published)	2026-10-10
Date researched	2026-10-27
Researched by	tai (agent), model: Muse Spark, on behalf of retoor
Research method	direct page fetch (patch headers and description; dependency/test-file diffs skimmed)
Confidence	High for the classification finding (stated plainly in the PR description), Medium for the Baileys internals (not independently read)
Status	Active

Summary

Baileys 7.0.0-rc12 dropped every protocol message from the phone on a new link as spoofed: its self-only guard required fromMe, but decodeMessageNode only set fromMe when the stanza carried a recipient attribute, and the phone's own peer stanzas on a new link (history sync notification, app-state key share) carry none. Result: no app-state keys, every collection failing with "failed to find key", contacts never arriving. Bumping to rc14 (whose guard accepts the phone's own sync stanzas) plus a regression test fixed it. The PR also notes WhatsApp otherwise sends saved names just once, at linking.

Key findings

• Peer stanzas from the phone on a new link have no recipient attribute; a classifier that needs one drops exactly the sync traffic.
• The failure is silent (logged as spoofed at best) and total: no keys, no contacts.
• The project pins the fix with a dedicated peer-stanza test.

Pros / strengths

• A clean demonstration that sync traffic needs its own classification rule, not the chat-message rule.
• The "sent just once, at linking" observation explains why a dropped first push is unrecoverable by re-request in some stacks.

Cons / limitations / caveats

• Baileys-specific (Baileys rc versions, process-message.js); the exact guard code was not read here.
• "Just once" is that project's operational experience, contradicted in the healthy case by whatsmeow stacks (wacli sees answers to re-requests); most likely the phone stops pushing only to companions that never consume the first push.

Relevance to tai

detz had the same class of bug in a different form: the own-sender filter accepted the PN user only, so a key share arriving from the phone's LID would have been silently dropped. WaClient::is_own_sender now accepts the PN or LID user (whatsmeow IsFromMe semantics, verified against whatsmeow main), and every arrival is logged before the filter. Covered by build/whatsapp_test section peer message helpers.

Changelog

Date	Change
2026-10-27	Initial dossier created.