channelData content excluded from dedup key

The key construction at line 55 does not include the channelData value — it only checks whether channelData is non-empty to avoid returning null for "empty" payloads. For payloads that consist entirely of channelData (no text, no mediaUrl/mediaUrls), the key collapses to out|${channel}|${account}|${to}|${thread}|||, which is identical for any two such payloads sent to the same recipient and thread.

This means two distinct channelData-only messages (e.g., two different Telegram flex/carousel layouts) delivered within the 30s TTL to the same recipient would collide on the same key — the second delivery would be silently suppressed as a false duplicate.

A serialized representation of channelData should be included in the key:

// After the existing key parts, include channelData fingerprint
const channelDataFingerprint = hasChannelData
  ? JSON.stringify(payload.channelData, Object.keys(payload.channelData ?? {}).sort())
  : "";

return `out|${channel}|${account}|${to}|${thread}|${normalizedText}|${sortedMediaUrls}|${replyTo}|${channelDataFingerprint}`;

This is a comment left during a code review.
Path: src/infra/outbound/outbound-dedupe.ts
Line: 40-55

Comment:
**`channelData` content excluded from dedup key**

The key construction at line 55 does not include the `channelData` value — it only checks whether `channelData` is non-empty to avoid returning `null` for "empty" payloads. For payloads that consist entirely of `channelData` (no `text`, no `mediaUrl`/`mediaUrls`), the key collapses to `out|${channel}|${account}|${to}|${thread}|||`, which is identical for any two such payloads sent to the same recipient and thread.

This means two distinct `channelData`-only messages (e.g., two different Telegram flex/carousel layouts) delivered within the 30s TTL to the same recipient would collide on the same key — the second delivery would be silently suppressed as a false duplicate.

A serialized representation of `channelData` should be included in the key:

```ts
// After the existing key parts, include channelData fingerprint
const channelDataFingerprint = hasChannelData
  ? JSON.stringify(payload.channelData, Object.keys(payload.channelData ?? {}).sort())
  : "";

return `out|${channel}|${account}|${to}|${thread}|${normalizedText}|${sortedMediaUrls}|${replyTo}|${channelDataFingerprint}`;
```

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

Unescaped | separator risks key collisions

The key uses a bare | as a field separator without escaping the field values. If any field (to, thread, channel, etc.) itself contains a | character, the resulting key is ambiguous. For example:

• { to: "a|b", threadId: "" } → ...||a|b||...
• { to: "a", threadId: "b" } → ...||a|b||...

Both produce the same segment, so messages to different recipients or threads could collide. While common channel identifiers (phone numbers, integer chat IDs) rarely contain pipes, custom channel IDs or topic thread identifiers might.

Consider using a separator that cannot appear in the field values (e.g. \0, or encoding fields with a safe delimiter), or using JSON.stringify([channel, account, to, thread, normalizedText, ...]) to produce an unambiguous composite key.

This is a comment left during a code review.
Path: src/infra/outbound/outbound-dedupe.ts
Line: 55

Comment:
**Unescaped `|` separator risks key collisions**

The key uses a bare `|` as a field separator without escaping the field values. If any field (`to`, `thread`, `channel`, etc.) itself contains a `|` character, the resulting key is ambiguous. For example:

- `{ to: "a|b", threadId: "" }` → `...||a|b||...`
- `{ to: "a", threadId: "b" }` → `...||a|b||...`

Both produce the same segment, so messages to different recipients or threads could collide. While common channel identifiers (phone numbers, integer chat IDs) rarely contain pipes, custom channel IDs or topic thread identifiers might.

Consider using a separator that cannot appear in the field values (e.g. `\0`, or encoding fields with a safe delimiter), or using `JSON.stringify([channel, account, to, thread, normalizedText, ...])` to produce an unambiguous composite key.

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

Include resolved reply target in outbound dedupe key

The dedupe key is built from payload before delivery, but the actual send target uses effectivePayload.replyToId ?? params.replyToId; this means two replies with identical text/media sent to the same chat but different top-level replyToId values are treated as duplicates and the second reply is skipped. This can drop legitimate threaded replies when payload-level replyToId is unset, so the dedupe params should include the resolved reply target used by sendOverrides.

Useful? React with 👍 / 👎.

Differentiate channelData payloads in dedupe key

The dedupe key string omits payload.channelData contents, so messages that share text/media/to/thread but carry different structured channel payloads (for example different LINE flex/template data or different button sets) collapse to the same key and later sends are suppressed for 30s. Because channelData changes delivery semantics, the key should include a stable representation/hash of it rather than only a presence check.

Useful? React with 👍 / 👎.

Serialize full channelData when building dedupe fingerprints

Using JSON.stringify(payload.channelData, Object.keys(payload.channelData!).sort()) only whitelists top-level keys, so nested properties are dropped from the fingerprint (for example two payloads with different channelData.template contents both stringify to the same value). In channels that send structured/nested payloads, distinct outbound messages can be treated as duplicates and skipped for 30 seconds.

Useful? React with 👍 / 👎.

Keep emoji-only outbound texts distinct in dedupe keys

The dedupe key uses normalizeTextForComparison, which strips emoji; for emoji-only messages this produces an empty normalized text, so different messages like "😀" and "😢" collapse to the same key for the same recipient/channel. That causes legitimate emoji-only sends within the TTL window to be dropped as duplicates.

Useful? React with 👍 / 👎.

Register per-dispatch dedupe keys only after successful delivery

The dispatcher marks a payload as delivered before options.deliver runs, and the key is never removed on error. If the first attempt fails transiently, any later identical payload in the same dispatch lifecycle is skipped, which blocks retry-by-reemission and can lose the reply entirely.

Useful? React with 👍 / 👎.

Atomically claim dedupe key before sending outbound payload

isOutboundDuplicate only performs a peek, so concurrent deliveries of the same payload can both observe a cache miss and proceed to send before either path calls registerOutboundDelivered; this leaves the race window that this layer is meant to close (e.g., two queue/tool executions starting at the same time). Because registration happens after network delivery in deliverOutboundPayloadsCore, dedupe is not effective for in-flight duplicates and should use an atomic claim/reserve step (with rollback on failure) instead of a read-then-write sequence.

Useful? React with 👍 / 👎.

Derive dedupe params from hook-modified payload

The dedupe key is built from payload before applyMessageSendingHook, but delivery uses effectivePayload after hooks may rewrite content; this means plugin-hook deployments can incorrectly suppress distinct outbound messages (same pre-hook payload, different post-hook text) and miss true duplicates (different pre-hook payloads rewritten to identical output). Build/check/register keys from the same effective payload that is actually sent.

Useful? React with 👍 / 👎.

Reserve dedupe key when enqueuing dispatcher payloads

The per-dispatch dedupe check runs before queuing, but the key is only inserted after await options.deliver(...), so two identical replies enqueued back-to-back in the same turn both pass has() and both get delivered. This means layer-3 dedupe does not actually block common synchronous duplicate emissions (tool/block/final bursts), and in dispatcher paths that send directly (without deliverOutboundPayloads), duplicate outbound messages still leak; the key should be claimed at enqueue time and removed on delivery failure.

Useful? React with 👍 / 👎.

Preserve media URL boundaries in dedupe fingerprint

Joining sorted media URLs with commas can collide distinct payloads when a URL itself contains commas (for example, ["a,b","c"] and ["a","b,c"] both fingerprint as "a,b,c"), which can incorrectly suppress non-duplicate media sends during the dedupe TTL window. The fingerprint should keep media URLs as a structured list (or another unambiguous encoding) instead of a delimiter-joined string.

Useful? React with 👍 / 👎.

Keep media URL order in the dedupe fingerprint

buildOutboundDedupeKey canonicalizes media with mediaUrls.toSorted(), so two payloads with the same files in different orders hash to the same key and one is dropped during the TTL window. In deliverOutboundPayloadsCore, media are actually sent in original order and the first item gets the caption, so ['a','b'] vs ['b','a'] are observably different outbound messages and should not be treated as duplicates.

Useful? React with 👍 / 👎.

Preserve emoji distinctions in normalized text dedupe keys

The key uses normalizeTextForComparison(rawText) whenever it is non-empty, and that normalization strips emoji; therefore messages like "Build passed ✅" and "Build passed ❌" collapse to the same dedupe key and the later send can be suppressed even though the meaning changed. The fallback to raw text only runs for emoji-only inputs, so mixed text+emoji status updates remain incorrectly conflated.

Useful? React with 👍 / 👎.