Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bug: WhatsApp linked device does not receive group messages (DMs work fine) [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#57989•Fetched 2026-04-08 01:55:13
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
jotastrongjotastrong
Participants
jotastrongjotastrongobviyusobviyus
Timeline (top)
closed ×1commented ×1cross-referenced ×1locked ×1

Root Cause

  • groupPolicy tested as allowlist and open — no change
  • Verbose mode shows zero group events at Baileys level
  • Standalone script with createWaSocket() + groupFetchAllParticipating() does receive group messages from active groups
  • Patching syncFullHistory:true has no effect because browser=["openclaw","cli",VERSION] doesn't trigger desktop sync path, and supportGroupHistory:false
  • Injecting groupFetchAllParticipating() after sendPresenceUpdate hydrates 114 groups but still no inbound
  • Relinking, leaving/rejoining group, waiting hours — nothing fixes it
  • Session that was receiving groups before had been running continuously for days

Fix Action

Fix / Workaround

  • groupPolicy tested as allowlist and open — no change
  • Verbose mode shows zero group events at Baileys level
  • Standalone script with createWaSocket() + groupFetchAllParticipating() does receive group messages from active groups
  • Patching syncFullHistory:true has no effect because browser=["openclaw","cli",VERSION] doesn't trigger desktop sync path, and supportGroupHistory:false
  • Injecting groupFetchAllParticipating() after sendPresenceUpdate hydrates 114 groups but still no inbound
  • Relinking, leaving/rejoining group, waiting hours — nothing fixes it
  • Session that was receiving groups before had been running continuously for days

PR fix notes

PR #58007: WhatsApp: hydrate participating groups on connect

Description (problem / solution / changelog)

Summary

This fixes a linked-device WhatsApp regression where DMs could arrive but group messages never started flowing on a freshly linked session.

Repro Steps

  1. Link a fresh WhatsApp companion device.
  2. Send a DM and confirm it arrives.
  3. Send a message in an existing group and observe that no inbound group event is delivered.

Root Cause

OpenClaw waited for the socket to connect and then started listening for inbound events, but it never explicitly hydrated participating groups. In current Baileys, groupFetchAllParticipating() only runs automatically after a dirty/groups sync event, so newly linked sessions could miss the group bootstrap needed to start receiving live group traffic.

Behavior Changes

  • Call groupFetchAllParticipating() once after the WhatsApp socket connects.
  • Keep startup resilient by swallowing hydration failures and continuing to send presence / process inbox traffic.
  • Add focused regression coverage for the successful and failing hydration paths.

Codebase and GitHub Search

  • Verified the current inbox bootstrap path in extensions/whatsapp/src/inbound/monitor.ts.
  • Verified current Baileys group bootstrap behavior and confirmed groupFetchAllParticipating() was not called by OpenClaw on connect.
  • Checked the reported regression in openclaw/openclaw#57989. lobster-biscuit

Tests

  • pnpm check ✅
  • pnpm build ✅
  • pnpm test -- extensions/whatsapp/src/session.test.ts extensions/whatsapp/src/inbound.media.test.ts extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test.ts extensions/whatsapp/src/monitor-inbox.captures-media-path-image-messages.test.ts extensions/whatsapp/src/monitor-inbox.blocks-messages-from-unauthorized-senders-not-allowfrom.test.ts extensions/whatsapp/src/monitor-inbox.allows-messages-from-senders-allowfrom-list.test.ts ✅
  • pnpm test ⚠️ fails on unrelated existing test src/tts/status-config.test.ts (provider expected auto, received microsoft)

Manual Testing

N/A

Sign-Off

  • Models used: Cursor agent
  • Submitter effort: investigated issue #57989 in current code, implemented the smallest targeted fix, and reran validation on the upstream-based branch
  • Agent notes: AI assistance was used for implementation and validation; the change is limited to WhatsApp inbox bootstrap behavior and regression tests

Made with Cursor

Changed files

  • extensions/whatsapp/src/inbound.media.test.ts (modified, +1/-0)
  • extensions/whatsapp/src/inbound/monitor.ts (modified, +14/-0)
  • extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test.ts (modified, +49/-0)
  • extensions/whatsapp/src/monitor-inbox.test-harness.ts (modified, +2/-0)
  • test/mocks/baileys.ts (modified, +2/-0)
RAW_BUFFERClick to expand / collapse

Environment

  • OpenClaw v2026.3.28
  • Ubuntu 24.04
  • Node v22.22.1

Symptom

After linking a WhatsApp Web companion device, the gateway receives DMs correctly but never receives group messages. messages.upsert never fires for group JIDs (@g.us). Sending TO groups works fine.

Reproduction Steps

  1. openclaw channels login --channel whatsapp (fresh QR link)
  2. Send a DM → arrives correctly ✅
  3. Send/receive in any group → zero inbound events in logs ❌

Investigation

  • groupPolicy tested as allowlist and open — no change
  • Verbose mode shows zero group events at Baileys level
  • Standalone script with createWaSocket() + groupFetchAllParticipating() does receive group messages from active groups
  • Patching syncFullHistory:true has no effect because browser=["openclaw","cli",VERSION] doesn't trigger desktop sync path, and supportGroupHistory:false
  • Injecting groupFetchAllParticipating() after sendPresenceUpdate hydrates 114 groups but still no inbound
  • Relinking, leaving/rejoining group, waiting hours — nothing fixes it
  • Session that was receiving groups before had been running continuously for days

Root Cause (suspected)

createWaSocket() does not call groupFetchAllParticipating() on connect, and init queries don't establish group Sender Key sessions. Combined with syncFullHistory:false and non-Desktop browser string, newly linked devices never get group message push.

Suggested Fix

Call sock.groupFetchAllParticipating() after connection open in the WhatsApp provider, or expose config options for syncFullHistory / supportGroupHistory.

extent analysis

Fix Plan

To resolve the issue of not receiving group messages, we need to call groupFetchAllParticipating() after the connection is open in the WhatsApp provider. Here are the steps:

  • Modify the WhatsApp provider to call sock.groupFetchAllParticipating() after connection open.
  • Expose config options for syncFullHistory and supportGroupHistory to allow for customization.

Example Code

// WhatsApp provider modification
const sock = createWaSocket();
sock.ev.on('open', () => {
  // Call groupFetchAllParticipating after connection open
  sock.groupFetchAllParticipating();
});
  • Add config options for syncFullHistory and supportGroupHistory:
// config.js
module.exports = {
  // ...
  whatsapp: {
    syncFullHistory: true, // or false
    supportGroupHistory: true, // or false
  },
};
  • Update the WhatsApp provider to use the config options:
// whatsapp-provider.js
const config = require('./config');
const sock = createWaSocket();
if (config.whatsapp.syncFullHistory) {
  // Enable sync full history
  sock.syncFullHistory = true;
}
if (config.whatsapp.supportGroupHistory) {
  // Enable support group history
  sock.supportGroupHistory = true;
}

Verification

To verify that the fix worked, follow these steps:

  • Relink the WhatsApp companion device.
  • Send a group message.
  • Check the logs for inbound group events.
  • Verify that messages.upsert fires for group JIDs (@g.us).

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#embedding generation#cache error#pipeline error#runtime error#dependency conflict

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING