A long reply has nowhere of its own, and nothing in the repository creates a thread #379

New issue

Closed

opened 2026-08-13 11:27:12 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-13 11:27:12 +00:00

Member

Slice of #239, and it delivers the trigger Kai specified on #354.

Lucia established the state on 239 and this does not repeat it: BindJobToThread and friends exist and are unwired, and nothing anywhere creates a thread.

Scope: turn replies only

A turn that posted a progress line and ran past turnLongReplyAfter puts its reply in a thread hung off the member's own message.

Both conditions are required. A turn that never posted a line has nothing in the channel pointing at a thread, and a member would be left with a question and no visible answer.

The carry-or-announce question dissolves

I raised it on 354 as a decision Kai had to make. It is already answered by code that predates the question: a long turn posts a progress line in the channel, and that line is the announcement. The reply lands in the thread and the channel keeps the line. Kai's threads-hide-after-an-hour setting then costs nothing, because the channel-side artifact was never the answer.

The name is derived, not authored

Discord requires a name and a name is member-facing. Letters, digits and spaces are kept from the member's own message, everything else is dropped, truncated to Discord's 100-rune cap, with a fixed fallback for a message that is all mention and punctuation. Dropped rather than summarised, because summarising is writing a member a title.

The property that matters more than the feature

A thread that cannot be made must never cost a member their reply. No permission, a channel type that cannot hold threads, an API failure, a turn already inside a thread — every one returns no thread rather than an error, and the reply goes to the channel exactly as today.

Out of scope

Threads for jobs. A job outlives its turn, so which thread it owns has a different answer, and the unwired binding stays unwired here.

Acceptance

A long turn's reply lands in a thread; a short turn is untouched.
Every failure path falls back to the channel.
A turn already in a thread does not nest, resolved from cached state with no API call.
The name stays inside Discord's cap and is never empty.

**Slice of** https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/239, and it delivers the trigger Kai specified on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/354. Lucia established the state on 239 and this does not repeat it: `BindJobToThread` and friends exist and are unwired, and **nothing anywhere creates a thread.** ## Scope: turn replies only A turn that posted a progress line and ran past `turnLongReplyAfter` puts its reply in a thread hung off the member's own message. Both conditions are required. A turn that never posted a line has nothing in the channel pointing at a thread, and a member would be left with a question and no visible answer. ## The carry-or-announce question dissolves I raised it on 354 as a decision Kai had to make. It is already answered by code that predates the question: **a long turn posts a progress line in the channel, and that line is the announcement.** The reply lands in the thread and the channel keeps the line. Kai's threads-hide-after-an-hour setting then costs nothing, because the channel-side artifact was never the answer. ## The name is derived, not authored Discord requires a name and a name is member-facing. Letters, digits and spaces are kept from the member's own message, everything else is dropped, truncated to Discord's 100-rune cap, with a fixed fallback for a message that is all mention and punctuation. Dropped rather than summarised, because summarising is writing a member a title. ## The property that matters more than the feature **A thread that cannot be made must never cost a member their reply.** No permission, a channel type that cannot hold threads, an API failure, a turn already inside a thread — every one returns no thread rather than an error, and the reply goes to the channel exactly as today. ## Out of scope Threads for jobs. A job outlives its turn, so which thread it owns has a different answer, and the unwired binding stays unwired here. ## Acceptance - A long turn's reply lands in a thread; a short turn is untouched. - Every failure path falls back to the channel. - A turn already in a thread does not nest, resolved from cached state with no API call. - The name stays inside Discord's cap and is never empty.

coilyco-ops referenced this issue from a commit

2026-08-13 11:27:34 +00:00

feat(threads): a long reply gets somewhere of its own

coilyco-ops referenced this issue from a pull request that will close it,

2026-08-13 11:27:55 +00:00

feat(threads): a long reply gets somewhere of its own #380

coilyco-ops referenced this issue

2026-08-13 11:28:30 +00:00

The ability to create and respond in threads does not seem to have been added yet #239

coilyco-ops closed this issue

2026-08-13 11:34:16 +00:00