Discord thread titles are clipped at ~30 characters #904

Closed
opened 2026-08-17 16:15:00 +00:00 by coilyco-ops-gaming · 3 comments

What happens

Thread names created through the Discord surface are clipped at roughly 30 characters, well below Discord's own 100-character thread name limit. Reported 2026-08-17 as still happening after a prior fix attempt.

What is known

  • Discord accepts thread names up to 100 characters, so the clip happens before the name reaches Discord.
  • The truncation looks like a harness- or MCP-side cut at around 30 characters.

What is unknown

  • Where the truncation is applied (harness turn data, the discord MCP server, or a composing step) and whether it counts runes or bytes.
  • Whether the earlier fix targeted a different truncation and this is a second one, or whether the fix regressed.

Ask

Raise the thread-name cap to Discord's actual limit (100 characters) and pin it with a test. Confirm whether the earlier clip fix is still in place so the two truncations are not mistaken for one.

## What happens Thread names created through the Discord surface are clipped at roughly 30 characters, well below Discord's own 100-character thread name limit. Reported 2026-08-17 as still happening after a prior fix attempt. ## What is known - Discord accepts thread names up to 100 characters, so the clip happens before the name reaches Discord. - The truncation looks like a harness- or MCP-side cut at around 30 characters. ## What is unknown - Where the truncation is applied (harness turn data, the discord MCP server, or a composing step) and whether it counts runes or bytes. - Whether the earlier fix targeted a different truncation and this is a second one, or whether the fix regressed. ## Ask Raise the thread-name cap to Discord's actual limit (100 characters) and pin it with a test. Confirm whether the earlier clip fix is still in place so the two truncations are not mistaken for one.
Author
Member

Still reproducing as of today: a fresh report from the Discord surface confirms thread titles are clipped at roughly 30 characters ("seems like the limit is 30 ish characters"), matching the original ~30-character cut. No evidence yet of a fix landing; the earlier truncation-fix question in the issue remains open. This is a re-confirmation, not new information.

Still reproducing as of today: a fresh report from the Discord surface confirms thread titles are clipped at roughly 30 characters ("seems like the limit is 30 ish characters"), matching the original ~30-character cut. No evidence yet of a fix landing; the earlier truncation-fix question in the issue remains open. This is a re-confirmation, not new information.
Author
Member

Scope update: the target cap is revised from Discord's full 100-character limit to the 40-60 character range. Any value in that range satisfies the request; suggest pinning 60 as the implementation constant and covering it with the same test that guards the truncation. The current ~30-character clip remains below the new lower bound, so the fix still needs to land regardless.

Scope update: the target cap is revised from Discord's full 100-character limit to the 40-60 character range. Any value in that range satisfies the request; suggest pinning 60 as the implementation constant and covering it with the same test that guards the truncation. The current ~30-character clip remains below the new lower bound, so the fix still needs to land regardless.
Member

Built and in review at #919. Angie (ENG, claude seat).

The clip is not a truncation, and that is why the earlier fix looked like it regressed. You asked where the cut is applied and whether it counts runes or bytes. Neither: nothing cuts at thirty.

threadTitleRunes was 50 and threadNameRunes was 100. The titler's own prompt said "Name this request in at most six words", and six words is about thirty characters. The bound was a ceiling the model never came near, so the reported length was the model complying, not a harness- or MCP-side cut.

That answers the "what is unknown" section: it is one instruction rather than a second truncation, and raising the cap on its own would have changed nothing a member could see.

What landed

  • SIRENS_ECHO_THREAD_TITLE_WORDS, default 9, new in config.go, with the prompt built from it the way the retry prompt is already built from the rune bound.
  • SIRENS_ECHO_THREAD_TITLE_RUNES 50 to 60, the value your scope update asked to pin.

Nine words reaches roughly 54 characters, inside the 40 to 60 range, and stays under 60 so the regeneration path does not start firing on every title.

Both earlier truncations, confirmed in place

  • threadNameRunes at 100 bounds the derived name at Discord's own cap, in threadNameFrom.
  • Regenerating an over-long title rather than trimming it, from #753, is unchanged, and the hard trim is still the second-failure fallback recording thread.title.trimmed.

Two bounds and one instruction, and the instruction was the binding one. The test that guards the regeneration asserted the literal "50 characters", which is exactly how a bound change strands a test, so it now builds that sentence from the knob.

Built and in review at https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/919. Angie (ENG, `claude` seat). **The clip is not a truncation, and that is why the earlier fix looked like it regressed.** You asked where the cut is applied and whether it counts runes or bytes. Neither: nothing cuts at thirty. `threadTitleRunes` was **50** and `threadNameRunes` was **100**. The titler's own prompt said *"Name this request in at most six words"*, and six words is about thirty characters. The bound was a ceiling the model never came near, so the reported length was the model complying, not a harness- or MCP-side cut. That answers the "what is unknown" section: it is one instruction rather than a second truncation, and **raising the cap on its own would have changed nothing a member could see**. ## What landed * `SIRENS_ECHO_THREAD_TITLE_WORDS`, default **9**, new in `config.go`, with the prompt built from it the way the retry prompt is already built from the rune bound. * `SIRENS_ECHO_THREAD_TITLE_RUNES` **50 to 60**, the value your scope update asked to pin. Nine words reaches roughly 54 characters, inside the 40 to 60 range, and stays under 60 so the regeneration path does not start firing on every title. ## Both earlier truncations, confirmed in place * `threadNameRunes` at 100 bounds the derived name at Discord's own cap, in `threadNameFrom`. * Regenerating an over-long title rather than trimming it, from #753, is unchanged, and the hard trim is still the second-failure fallback recording `thread.title.trimmed`. **Two bounds and one instruction, and the instruction was the binding one.** The test that guards the regeneration asserted the literal `"50 characters"`, which is exactly how a bound change strands a test, so it now builds that sentence from the knob.
Sign in to join this conversation.
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
coilyco-gaming/sirens-echo#904
No description provided.