Greptile Summary

This PR introduces a shared groupMetadataCache (Map<string, GroupMetadata>) that persists hydrated Baileys group metadata across reconnect cycles. On each connection, groupFetchAllParticipating populates the cache; if a subsequent sock.groupMetadata(jid) call fails during reconnect churn (e.g., 408), the code falls back to the persisted entry rather than returning empty metadata. The cache is also wired into the Baileys socket via cachedGroupMetadata so the protocol layer can skip redundant fetches on reconnect. A focused regression test validates the end-to-end recovery path.

Confidence Score: 5/5

Safe to merge — the change is well-scoped, consistent across all call sites, and backed by a targeted regression test.

No logic bugs found. The shared cache is threaded correctly through monitorWebInbox, attachWebInboxToSocket, WhatsAppConnectionController, and auto-reply/monitor.ts. The stale-fallback TTL behaviour is consistent with the existing cache design. No security or data-integrity concerns were identified.

No files require special attention.

_{Reviews (1): Last reviewed commit: "fix(whatsapp): recover group inbound aft..." | Re-trigger Greptile}

Codex review: needs maintainer review before merge.

Keep open. This is a maintainer-owned PR with the protected maintainer label, and current main still does not contain the PR's shared WhatsApp group metadata fallback or shorter post-reconnect app-silence recovery behavior. The latest PR context says the earlier cache growth concern was addressed on the branch, so the right next step is maintainer review/landing rather than cleanup closure.

Maintainer follow-up before merge:

Keep this PR open for explicit maintainer review. If the bounded-cache and stale-data tradeoff is acceptable and CI/Testbox proof remains current, land the WhatsApp plugin recovery patch with its focused regression coverage, then close the canonical WhatsApp group inbound issue after merge.

Best possible solution:

Keep this PR open for explicit maintainer review. If the bounded-cache and stale-data tradeoff is acceptable and CI/Testbox proof remains current, land the WhatsApp plugin recovery patch with its focused regression coverage, then close the canonical WhatsApp group inbound issue after merge.

What I checked:

• Protected maintainer item: The provided GitHub context identifies the PR author association as MEMBER and includes the protected maintainer label, which the cleanup policy keeps open for explicit maintainer handling.
• Current main lacks shared reconnect metadata fallback: Current main keeps groupMetaCache local inside attachWebInboxToSocket; there is no MonitorWebInboxOptions.groupMetadataCache shared through monitorWebChannel, so cached group metadata cannot survive listener reconnects the way the PR proposes. (extensions/whatsapp/src/inbound/monitor.ts:237, 48683a7f71b0)
• Current main hydrates groups without retaining them for fallback: Current main calls sock.groupFetchAllParticipating() on connect but only logs the count; it does not store the returned metadata into a shared fallback cache for later reconnect-time fetch failures. (extensions/whatsapp/src/inbound/monitor.ts:733, 48683a7f71b0)
• Current main lacks shorter recent-inbound watchdog recovery: Current main has no openedAfterRecentInbound or lastHandledInboundAt state, and the watchdog always uses the longer appSilenceTimeoutMs rather than the normal message timeout for a recently active post-reconnect recovery window. (extensions/whatsapp/src/connection-controller.ts:600, 48683a7f71b0)
• PR branch scope and security pass: The fetched PR diff is limited to WhatsApp plugin code/tests plus docs and changelog. It does not change workflows, dependencies, lockfiles, install scripts, release scripts, package publishing metadata, or other supply-chain execution surfaces. The latest diff also bounds the shared group metadata fallback with summarized entries, a 5 minute TTL, and a 500 entry recency cap, matching the maintainer follow-up comment on commit 2b40dc3. (extensions/whatsapp/src/inbound/monitor.ts, 2b40dc3a2d55)
• Related reports remain the intended target: The PR body explicitly targets canonical issue WhatsApp group inbound messages silently drop after repeated 408 reconnect cycles (DMs survive) #66920 and related WhatsApp reliability evidence in Improve WhatsApp/Baileys group message reliability #7433, WhatsApp: stale socket causes silent message loss (connection appears live but drops inbound messages) #63855, and [Bug]: WhatsApp listener repeatedly disconnects/stalls on Windows, causing "No active WhatsApp Web listener" and missed messages #70856, while separating QR-pairing and broader gateway-wedge reports. That makes the PR an active implementation candidate, not an obsolete cleanup item.

Likely related people:

• vincentkoc: Repository member, self-assigned on the PR timeline, authored the current PR head, and posted the maintainer follow-up explaining the bounded-cache response to Aisle/ClawSweeper review. This routes the active branch review even though it is not proof of current-main authorship. (role: active maintainer / PR owner; confidence: high; commits: e2738bfeb24a, 2b40dc3a2d55; files: extensions/whatsapp/src/inbound/monitor.ts, extensions/whatsapp/src/connection-controller.ts, extensions/whatsapp/src/auto-reply/monitor.ts)
• Peter Steinberger: Available current-main blame and log for the relevant WhatsApp monitor/controller/test/docs files point to Peter's recent commit beb1d9b touching the central paths, and current HEAD is also authored by Peter. This is the best current-main routing signal from local history. (role: recent current-main maintainer / adjacent owner; confidence: medium; commits: beb1d9b4815d, 48683a7f71b0; files: extensions/whatsapp/src/inbound/monitor.ts, extensions/whatsapp/src/connection-controller.ts, extensions/whatsapp/src/auto-reply/monitor.ts)

Remaining risk / open question:

• Cleanup policy should not auto-close maintainer-owned or protected-label PRs.
• Current main still lacks the PR's core WhatsApp reconnect recovery behavior, so closing now would discard an active fix candidate for WhatsApp group inbound messages silently drop after repeated 408 reconnect cycles (DMs survive) #66920 and related reports.
• The branch's cache growth concern appears addressed by TTL, summarized entries, and a 500 entry cap, but cached group metadata can still be stale within the TTL; that tradeoff belongs in normal maintainer review.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 1c45592e620e.

Maintainer follow-up:

• Addressed the Aisle/Clawsweeper cache concern in 2b40dc3: the shared WhatsApp group metadata fallback now stores only summarized inbound fields, expires entries on the existing 5 minute metadata TTL, and evicts by recency at 500 entries.
• Rebased onto current origin/main, resolving the watchdog conflict by preserving the newer transport-timeout path and keeping the shorter post-reconnect app-silence recovery window.
• No inline review threads are open.

Testbox proof (tbx_01kqcapechhya4az5qe029xdds):

• OPENCLAW_TESTBOX=1 pnpm docs:list
• OPENCLAW_TESTBOX=1 pnpm test:serial extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test-support.ts extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts extensions/whatsapp/src/connection-controller.test.ts (69 files / 670 tests)
• OPENCLAW_TESTBOX=1 pnpm check:changed

Maintainer follow-up after Aisle refresh:

• Added dac1f92 to minimize the shared reconnect metadata cache: it now stores only group subject + TTL/LRU state, not full participant identifiers. Live per-message metadata behavior remains unchanged, but reconnect fallback no longer resurrects cached phone-number/member lists into inbound prompt context.
• The same change removes eager participant resolution from groupFetchAllParticipating() hydration, so connect-time shared hydration no longer fans out over every group participant.
• Added/kept regression coverage in 8d428d7.

Fresh Testbox proof on replacement box tbx_01kqcdbvs897xcgfgser05fdsc:

• OPENCLAW_TESTBOX=1 pnpm test:serial extensions/whatsapp/src/monitor-inbox.streams-inbound-messages.test-support.ts extensions/whatsapp/src/auto-reply.web-auto-reply.connection-and-logging.e2e.test.ts extensions/whatsapp/src/connection-controller.test.ts passed: WhatsApp e2e + extension shard, 69 files / 670 tests.
• OPENCLAW_TESTBOX=1 pnpm check:changed passed.

Earlier box tbx_01kqcapechhya4az5qe029xdds was stopped after SSH sync failures (publickey/timeout) and replaced.