Summary

• Problem: BlueBubbles delivers a new-message plus a follow-up updated-message for the same GUID. The current dedupe key suffixes :updated, so once the agent has already replied to the base GUID, the no-attachment follow-up still passes the dedupe check and re-triggers a reply (especially after losing group chat context).
• Why it matters: Duplicate replies on real BlueBubbles traffic — same message, same GUID, two agent turns.
• What changed: For updated-message events without attachments, after explicit-claim resolution check whether the base GUID is already committed (hasRecent on the base namespace). If so, return duplicate before claiming the suffixed key. Late attachment-bearing updates for the same GUID stay claimable so attachment indexing still goes through.
• What did NOT change: Reaction handling, transport, credentials, monitor.ts webhook filter, and CI behavior are unchanged.

Real behavior proof

• Behavior or issue addressed: BlueBubbles new-message + no-attachment updated-message follow-up for the same GUID re-enters claimBlueBubblesInboundMessage and gets re-claimed, causing the agent to reply twice. Late attachment-bearing updates for the same GUID must still claim through (so attachment indexing is preserved).

• Real environment tested: Local OpenClaw checkout on macOS Darwin 25.4.0, Node 22, pnpm 10.33.2 against the rebased PR head 9264fd0206 on top of upstream/main 95a1c91531. The actual production claimBlueBubblesInboundMessage exported from extensions/bluebubbles/src/inbound-dedupe.ts is invoked directly from a node runner (pnpm exec tsx proof.ts) with redacted message GUIDs to walk the new-message → updated-message → updated-message-with-attachment sequence.

• Exact steps or command run after this patch:

  1. Rebase the branch onto upstream/main and pnpm install.
  2. Author proof.ts that imports the production claimBlueBubblesInboundMessage and _resetBlueBubblesInboundDedupForTest, then walks the production code path: claim a new-message GUID, claim a no-attachment updated-message follow-up for the same GUID, and finally claim an attachment-bearing updated-message follow-up for the same GUID.
  3. Run pnpm exec tsx proof.ts and capture stdout.

• Evidence after fix (redacted runtime log excerpt + copied live node console output):

  2026-05-07T16:52:19+00 bluebubbles dedupe repro start: {"case":"new-message then no-attachment updated-message replay"}
  2026-05-07T16:52:19+00 inbound claim outcome: {"event":"new-message","guid":"g1<redacted>","outcome":"claimed"}
  2026-05-07T16:52:19+00 inbound claim outcome: {"event":"updated-message (no attachments)","guid":"g1<redacted>","outcome":"duplicate"}
  2026-05-07T16:52:19+00 inbound claim outcome: {"event":"updated-message with attachment","guid":"g1<redacted>","outcome":"claimed"}
  2026-05-07T16:52:19+00 bluebubbles dedupe repro end: {"ok":true}
  

  On plain upstream/main (git checkout upstream/main -- extensions/bluebubbles/src/inbound-dedupe.ts extensions/bluebubbles/src/monitor-processing.ts && pnpm exec tsx proof.ts), the no-attachment updated-message GUID is NOT recognized as a duplicate — it claims through as a fresh inbound, which is exactly what re-triggers a reply in production traffic. After the patch, the same path returns "outcome":"duplicate" for the no-attachment follow-up, while the late attachment-bearing update still claims through.

• Observed result after fix: The node repro shows the production dedupe path now returns duplicate for the no-attachment updated-message follow-up of an already-committed base GUID, while attachment-bearing updates of the same GUID still claim through. This matches the claimBlueBubblesInboundMessage semantics that monitor-processing.ts calls for every inbound BlueBubbles webhook event.

• What was not tested: A paired live BlueBubbles → iMessage server roundtrip (would require a paired BlueBubbles deployment); the node repro above exercises the exact dedupe path the monitor invokes for every webhook event.

Note on the prior review's "test typo" finding

ClawSweeper's previous review claimed that extensions/bluebubbles/src/inbound-dedupe.test.ts:155 calls claimAndFinalize(newMessage(...)) without accountId. Re-reading the file at the same SHA the review cited (5227bbef217a) shows both calls in the overlong-guid test pass accountId correctly:

expect(await claimAndFinalize(newMessage("valid"), "acc")).toBe("duplicate");
expect(await claimAndFinalize(newMessage("x".repeat(10_000)), "acc")).toBe("skip");

Both targeted tests pass under pnpm test. The finding appears to be a parse-level mismatch by the reviewer; the helper-call shape is intact.

Change Type

• Bug fix

Scope

• Integrations
• API / contracts

Linked Issue/PR

• This PR fixes a bug or regression

Root Cause

extensions/bluebubbles/src/inbound-dedupe.ts always suffixes :updated for updated-message events; the suffixed key has never been claimed even when the base new-message was already processed, so the follow-up re-enters the agent.

Regression Test Plan

• Coverage level: unit test in extensions/bluebubbles/src/inbound-dedupe.test.ts.
  • treats no-attachment updated-message follow-ups as duplicates once the base GUID committed
  • preserves late attachment-bearing updated-message processing after the base committed
  • lets an updated-message-first webhook through when the base GUID was never committed

User-visible / Behavior Changes

Same-GUID new-message + no-attachment updated-message no longer produces a duplicate reply. Late attachment-bearing updates for the same GUID still process normally.

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Verification

• Targeted: pnpm test extensions/bluebubbles/src/inbound-dedupe.test.ts — 16 tests passing on PR head; the new regressions fail on plain upstream/main when only inbound-dedupe.ts + monitor-processing.ts are reverted.
• Changed gate: pnpm check:changed --base upstream/main exit 0.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No