Closing this PR because the author has more than 10 active PRs in this repo. Please reduce the active PR queue and reopen or resubmit once it is back under the limit. You can close your own PRs to get back under the limit.

Greptile Summary

This PR refreshes the BlueBubbles webhook replay-dedupe branch off current main, fixing several edge cases in how duplicate and edited messages are handled.

Key changes:

• buildInboundReplayKey now includes the event type (new-message vs updated-message), edit metadata (itemType, dateEdited), and reply context — preventing same-text edit reversions from colliding with the original send's dedupe key
• updated-message events bypass debounce coalescing entirely, so a rapid typo-fix edit can't merge its body into the original buffered new-message
• shouldIgnoreUpdatedNonConversationalEvent filters delivery/playback state noise (UUID churn, empty-no-signal payloads) while explicitly preserving media-only payloads and UUID-text edits that carry real edit metadata
• Replay lifecycle callbacks (onFlushSuccess / onFlushFailure) wire debounce-flush outcomes back into the pending-key tracking so a failed flush doesn't permanently mark a message as seen, and a pending deferred retry is re-enqueued atomically
• monitor.ts also now exports _resetBlueBubblesWebhookReplayState for clean test isolation
• src/plugin-sdk/bluebubbles.ts adds createDedupeCache and beginWebhookRequestPipelineOrReject to the facade surface that monitor.ts imports from
• The test file is substantially refactored: external helpers are inlined, making each test self-contained; new test cases cover all the edge cases described above

Confidence Score: 5/5

• Safe to merge — logic is sound, edge cases are well-tested, and the only finding is a trivial duplicate reset call in test setup.
• The implementation correctly handles all the described scenarios with proper error propagation, atomic state transitions in the retry lifecycle, and thorough test coverage. The peek/check split on the dedupe cache is correct. The retryReenqueuedFromFlushFailure guard properly prevents the .catch handler from clearing the pending key when a retry has already been re-enqueued. The only issue found is a harmless duplicate resetBlueBubblesSelfChatCache() call in beforeEach.
• No files require special attention.

This is a comment left during a code review.
Path: extensions/bluebubbles/src/monitor.test.ts
Line: 254

Comment:
**Duplicate `resetBlueBubblesSelfChatCache` call in `beforeEach`**

`resetBlueBubblesSelfChatCache()` is called twice in a row at lines 253–254. The second call is a no-op (the cache is already empty), but it looks like an accidental copy-paste.

```suggestion
    resetBlueBubblesSelfChatCache();
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(bluebubbles): dedupe webhook replays..." | Re-trigger Greptile}