-
-
Notifications
You must be signed in to change notification settings - Fork 69.1k
fix(slack): app_mention events silently dropped by dedup cache when message event arrives first #34833
Copy link
Copy link
Description
Problem
Slack delivers both message and app_mention events for the same @mention in channels, with no guaranteed delivery order. OpenClaw's dedup cache uses the same channelId:ts key for both event types — whichever arrives first marks the message as seen, and the second is silently dropped.
When message arrives first in a channel with requireMention: true:
messageevent is dropped by therequireMentioncheck (no mention flag) — but the dedup key is still setapp_mentionevent arrives withwasMentioned: true— silently deduped
Result
- ~50% of @mentions in channels are silently ignored
- Thread context never established (
threadTsResolver.resolvenever runs) invalid_thread_tserrors on reply → fallback to main channel
Reproduction
This is timing-dependent. In a multi-agent Slack setup where agents @mention each other in channels, approximately half of mentions are dropped. Slack provides no ordering guarantees between message and app_mention (confirmed by Slack team).
Proposed Fix
Exempt app_mention events from the dedup check in message-handler.ts. This is safe because:
- The downstream debouncer already handles dedup at the flush level via
buildKey prepareSlackMessagecorrectly mergeswasMentionedacross debounced entries
Related
- [Bug]: app_mention events silently dropped by dedup cache when message event arrives first #20151 — original report (closed, but PR fix(slack): allow app_mention events to bypass dedup cache #20152 was never merged)
a1ee60549— fixes a different issue: duplicate DM processing. That fix skipsapp_mentionforim/mpimchannels. This issue is about channel mentions being dropped by the dedup cache.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
Type
Fields
Give feedbackNo fields configured for issues without a type.