Bug: Long messages (>1900 chars) are sent duplicate to Discord

[thepagent]

Summary

When an agent reply exceeds ~1900 characters, the message chunks are sent to Discord twice, resulting in duplicate messages visible to users.

Root Cause

In src/discord.rs → stream_prompt, there are two independent code paths that both call channel.say() for overflow chunks:

1. Edit-streaming task (live updates every 1.5s)

if content.len() > 1900 {
    let chunks = format::split_message(&content, 1900);
    // ...
    for chunk in chunks.iter().skip(1) {
        if let Ok(new_msg) = channel.say(&ctx.http, chunk).await {  // ← sends chunks
            current_edit_msg = new_msg.id;
        }
    }
}

2. Final edit (after streaming completes)

let chunks = format::split_message(&final_content, 2000);
for (i, chunk) in chunks.iter().enumerate() {
    if i == 0 {
        let _ = edit(&ctx, channel, current_msg_id, chunk).await;
    } else {
        let _ = channel.say(&ctx.http, chunk).await;  // ← sends chunks again
    }
}

Both paths send new messages for chunks beyond the first, with no coordination between them.

Steps to Reproduce

1. Ask the agent a question that produces a long reply (>1900 chars)
2. Observe duplicate message chunks in the Discord thread

Suggested Fix (pick one)

Option A: Edit-streaming task should only edit() the first message, never say() new chunks. Leave all chunking to the final edit.

Option B: Track message IDs created by the edit-streaming task and pass them to the final edit, so it edits existing messages instead of creating new ones.

Option A is simpler — during streaming, just truncate to 1900 chars with a ... indicator, then let the final edit handle the full multi-chunk output.

[thepagent]

We've done an initial analysis and have a draft fix in #82 along with debug logging in #84, but we're not merging either yet — we want more data first.

If you're hitting this issue, here's how you can help:

1. Log chunks locally — PR debug: add tracing to streaming chunk logic for #81 analysis #84 adds debug! tracing to the streaming chunk logic. You can cherry-pick that branch (debug/log-streaming-chunks), run with RUST_LOG=agent_broker=debug, trigger a long reply, and share the log output here.
2. 👍 this issue if you've seen duplicate messages with long replies — helps us gauge how widespread this is.

We welcome contributors to investigate further and share findings to move this forward. 🙏

[ruan330]

We hit this exact issue in production and submitted a fix in PR #53 (filed before the rename).

Root cause confirmed: the edit-streaming task creates overflow messages via channel.say() with message IDs tracked only inside the spawned task. The final edit uses the original message ID and creates its own overflow — the streaming messages are never cleaned up.

Our fix in #53: during streaming, only edit the single placeholder message. If content exceeds 1900 chars, truncate with "…" — this is a live preview, not the final output. The final edit handles proper multi-message splitting after streaming completes.

// During streaming: single-message edit, truncate if needed
let display = if content.len() > 1900 {
    format!("{}…", &content[..1900])
} else {
    content.clone()
};
let _ = edit(&ctx, channel, current_edit_msg, &display).await;

This cleanly separates responsibilities:

• Streaming = live preview in one message (truncated if needed)
• Final edit = authoritative delivery, split across messages if needed

No orphaned messages, no duplication. PR #53 also includes a separate toolCallId matching fix — happy to split into two PRs if that's preferred.

[chengli]

Confirming this in production with claude-agent-acp@0.25.0 (kakashi backend in our fleet). Fresh repro with RUST_LOG=openab=debug,info below. Per @thepagent's request for chunk-level data.

Reproduction trigger

User question that produced ~9 tool calls (Bash×3, Grep×1, Read File×5) followed by a ~3000-char zh-TW analysis. The streaming compose_display content hovered around 2000 chars.

Discord-side evidence

msg id	ts	len	md5
…067492855959 (anchor)	17:50:27	1191	b0ef889c4ff6
…282618834955	17:51:18	1098	c80237275921
…291296718959	17:51:20	1098	c80237275921
…302545842198	17:51:23	1098	c80237275921
…321554563103	17:51:27	653	(final tail)
…329477734552	17:51:29	581	(final tail)

Three messages between 17:51:18 and 17:51:23 are byte-identical (verified by md5). Posted ~2–3 s apart inside the streaming window.

ACP-side timing

• 17:50:27 — user msg; openab spawns claude-agent-acp, session created
• 17:50:33 → 17:50:55 — 9 tool_call events
• 17:51:09 → 17:51:28 — 60 agent_message_chunk events stream in (~19 s)
• 17:51:28 — stop_reason: end_turn

No session reset, no errors, no prompt_done until end_turn. The 3 duplicates land squarely inside the streaming window.

What this confirms

The 1098-byte duplicates correspond to chunk[1] of format::split_message(content, 1900) running 3 successive iterations of the streaming loop. The text buffer was growing slightly each iteration (text streaming in), so the if content != last_content dedupe passed each time and the GT-1900 path fired. The chunks split at the same line boundary so chunk[1] was identical 1098 bytes — but channel.say was called fresh each iteration with no slot tracking, producing 3 copies. Lines up with @ruan330's PR #53 root-cause analysis.

Caveat / interesting wrinkle

The duplicate count we saw (3) is interesting because the user-facing reply from claude was only ~3000 chars total — well under the 1900 + overflow boundary normally needed to trigger. The trigger was the tool_lines accumulation before the analysis text even started streaming: 9 tool calls each producing a `🔧 Tool... ✅` line consumed enough chars that the displayed `compose_display(&tool_lines, &text_buf)` crossed 1900 well before the assistant body did.

Offer

Happy to test PR #82 / PR #53 against the same trigger and report back. Just say which branch you want priority on.

[chaodu-agent]

Issue at a Glance

Agent responds with 3000-char message
         │
         ▼
    Edit-streaming task (line 232-238):
    content > 1900 → split → channel.say() chunks ← sends 1st time
         │
         ▼
    Final edit (line 305-310):
    split_message → channel.say() chunks ← sends 2nd time ❌
         │
         ▼
    User sees duplicate chunks in Discord

Hi @thepagent,

Confirmed — both code paths still exist on latest (discord.rs lines 238 and 310). Two independent channel.say() calls for overflow chunks with no coordination.

Option A (truncate during streaming, let final edit handle chunking) is the simpler fix. PR #53 may partially overlap — worth checking before starting a new PR.