Discord long message.send split pair is duplicated after run completion despite messaging-tool suppression

Summary

A Discord channel/thread turn that explicitly delivered a long visible reply via message(action=send) produced a duplicated pair of Discord messages:

1. message(action=send) successfully posted the long reply, which Discord/OpenClaw split into two messages.
2. Shortly after run completion, the same long reply was delivered again via the normal/final delivery path, also split into the same two-message shape.

This looks related to #44467 and #65493, but the already-shipped messagingToolSentTexts / delivery-mirror suppression did not prevent this Discord split-message case on OpenClaw 2026.5.12.

Observed evidence

Environment:

• OpenClaw: 2026.5.12
• Surface: Discord channel/thread session
• Sender pattern: assistant explicitly called message(action=send) for visible output, then final assistant output was intended to be silent/NO_REPLY.
• The reply was long enough to be split by Discord outbound chunking.

Observed Discord messages:

• First delivered split pair:
  • 1505846828413747270
  • 1505846829349077123
• Duplicate delivered split pair:
  • 1505846840614977587
  • 1505846843081228400

The duplicate was not duplicate text inside one message. It was two separate repeated Discord message pairs: the same logical long reply was split into two chunks, then that split pair was delivered a second time.

Why this appears to be a remaining gap

#44467 and #65493 were closed as implemented, with evidence that current/main and released builds suppress the generic duplicate paths:

• transcript-only openclaw/delivery-mirror and openclaw/gateway-injected assistant messages are ignored in handleMessageEnd();
• successful message.send completions are committed to messagingToolSentTexts / normalized dedupe state;
• message_end block replies are skipped when the text duplicates a successful messaging-tool send;
• regression tests cover generic message-tool duplicate suppression and delivery-mirror ignore behavior.

The local 2026.5.12 install also contains those guards (messagingToolSentTexts, delivery-mirror filtering, and Skipping message_end block reply - already sent via messaging tool).

However, the Discord split-pair duplication still occurred, so the generic suppression is not sufficient for this route. Possible causes:

• same-target matching fails for Discord thread/channel metadata after explicit message.send;
• split outbound Discord chunks are not recorded/normalized in the same way as the final/main delivery text;
• suppression compares the unsplit final text against split/chunked delivery evidence incorrectly;
• the auto-final delivery path for Discord channel sessions bypasses the same embedded-session suppression path covered by the existing tests.

Expected behavior

For a Discord channel/thread turn:

1. Assistant calls message(action=send) with a long text.
2. Discord outbound delivery splits the text into N messages.
3. The run completes with no additional visible final reply.
4. OpenClaw must not send the same logical reply again through delivery-mirror/main/final delivery, whether as one message or as another N split chunks.

Suggested regression test

Add a regression test covering this exact shape:

• source surface: Discord channel/thread session;
• assistant uses message(action=send) to same target;
• sent text is long enough to trigger Discord splitting/chunking;
• run then reaches message_end / final delivery with the same logical assistant text or a delivery-mirror transcript entry;
• assert only one split batch is sent and the second/final split batch is suppressed.

The test should verify dedupe at the logical-message level, not only exact single-message text equality.

Related issues

• #44467 — message.send triggers duplicate delivery-mirror replies
• #65493 — Bug: delivery-mirror duplicates messages sent via message(action=send) tool