fix(discord): show full long clarify options - #73545
Open
merlincat11 wants to merge 2 commits into
Open
Conversation
merlincat11
force-pushed
the
fix/discord-long-clarify-options
branch
from
July 29, 2026 00:20
ec52807 to
bf63375
Compare
teknium1
reviewed
Jul 30, 2026
teknium1
left a comment
Contributor
There was a problem hiding this comment.
Thanks for preserving the existing callbacks and button semantics while addressing a real mobile readability issue.
Problems
- Blocking:
plugins/platforms/discord/adapter.py:6813createsFull optionswith an unbounded join.tools/clarify_tool.py:225-228limits only choice count, not choice length, so a valid clarify call can exceed Discord's 1024-character embed-field value limit and cause the prompt send to fail. Add a field budget and cover the overflow boundary. plugins/platforms/discord/adapter.py:6752-6773states that interactive payloads must be mirrored in plain content because embeds can be invisible or separated from controls on web/mobile. The proposed change leaves clarify content unchanged, so those clients still lack readable full options. Mirror the numbered list intoclarify_tail, bounded independently for message content.
Suggested changes
- Cap the rendered embed field and reserve suffix space before truncation; add a long-options regression test.
- Include the complete/bounded numbered options in the plain-content mirror and test that payload.
Automated hermes-sweeper review.
| ): | ||
| embed.add_field( | ||
| name="Full options", | ||
| value="\n".join( |
Contributor
There was a problem hiding this comment.
Blocking: this join has no embed-field budget. clarify limits choice count but not individual choice length, so valid long choices can exceed Discord's 1024-character field-value limit and make the entire clarify send fail. Truncate the rendered list with room for any suffix and add an overflow-boundary test.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Full optionsembed field when any normalized Discord clarify option exceeds the existing 40 UTF-16-unit mobile-safe threshold.Why this matters
Discord accepts button labels up to 80 UTF-16 units, but its mobile client can visibly clip labels much earlier. Today, the embed only says to pick a button, so a mobile user may be asked to choose among options they cannot fully read.
Mirroring complete numbered choices in the embed makes the decision readable without redesigning the interaction. The field is conditional, so ordinary short prompts retain their current compact presentation.
Before / after
Before
The native Discord mobile screenshot shows all three choice labels clipped with ellipses:
After, only when an option exceeds 40 UTF-16 units
The screenshot above is native Discord mobile evidence of the broken state. A native after-screenshot is not attached because this headless development environment cannot render the mobile client. The exact outgoing embed fields and unchanged button labels are asserted by the regression tests and were also exercised through the adapter's rendered payload.
Prior art / duplicate audit
Related open PR: #62291 addresses the same clipping symptom by changing every choice button to a numeric-only label and always mirroring choices. This PR is intentionally narrower: it preserves the existing buttons and adds full embed text only when a choice crosses the mobile-safe threshold.
How to test
Results:
git diff --check: cleanPlatforms tested