Skip to content

fix: prevent duplicate messages for long replies (>1900 chars)#179

Closed
masami-agent wants to merge 3 commits intoopenabdev:mainfrom
masami-agent:fix/duplicate-long-messages
Closed

fix: prevent duplicate messages for long replies (>1900 chars)#179
masami-agent wants to merge 3 commits intoopenabdev:mainfrom
masami-agent:fix/duplicate-long-messages

Conversation

@masami-agent
Copy link
Copy Markdown
Contributor

Summary

Fixes the duplicate message bug when agent replies exceed 1900 characters.

Closes #81

Before (current main)

The edit-streaming task splits long content into chunks via channel.say(), and the final edit does the same independently — resulting in duplicate overflow messages.

After (this PR)

  • Streaming task: only edits a single placeholder message. If content exceeds 1900 chars, truncates with — this is a live preview, not the final output.
  • Final edit: handles proper multi-chunk delivery via split_message() after streaming completes.

Clean separation of responsibilities, no orphaned messages, no duplication.

Changes

File Change
src/discord.rs Replace streaming split+say logic with truncate+edit (−13 / +6 lines)

Approach

Option A from the issue: truncate during streaming, let final edit handle chunking. Same approach as the community fix in PR #53 by @ruan330.

During streaming, truncate content at 1900 chars with '…' instead of
splitting into multiple messages via channel.say(). The final edit
after streaming completes handles proper multi-chunk delivery.

Previously both the streaming task and final edit independently called
channel.say() for overflow chunks, causing duplicates.

Closes openabdev#81
content[..1900] can panic if 1900 falls inside a multi-byte UTF-8
character (e.g. CJK, emoji). Walk back to the nearest char boundary.
Discord's 2000-char limit is Unicode characters, not bytes. CJK chars
are 3 bytes each, so byte-based limits truncate far too early and
as_bytes().chunks() corrupts multi-byte characters.

- discord.rs: streaming truncation uses chars().count() / chars().take()
- format.rs: split_message uses char count for all boundary checks,
  hard-split iterates chars instead of byte chunks
@masami-agent
Copy link
Copy Markdown
Contributor Author

Closing in favor of #135 which addresses the same issue, was submitted earlier, and has been production-verified. Will provide review feedback on #135 instead.

Apologies for the duplicate — should have checked for existing PRs before opening this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant