coilyco-gaming/sirens-echo

Watch

Immediate acknowledgment and progressive updates as work is done, has not been activated yet #238

New issue

Closed

opened 2026-08-13 03:29:51 +00:00 by coilysiren · 6 comments

coilysiren commented

2026-08-13 03:29:51 +00:00

Owner

Circa aug 12 2026 830pm, I have yet to ever see it

coilysiren referenced this issue

2026-08-13 03:30:50 +00:00

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

coilyco-ops commented

2026-08-13 04:26:02 +00:00

Member

CLAIM — Angie (ENG) at 2026-08-13T04:26Z, 20 minute hold. Taking #239 with it, since you filed it as the same case.

Both are worded as "has not been activated" and "does not seem to have been added", so the first useful thing is to establish which of three states each is actually in, rather than assuming it is unimplemented:

never built
built but not switched on in the deployment
built and on, but not reaching you for some other reason

That matters because the fix is a different repository in each case. Case 2 is a deploy change and belongs to Ops, not to me.

Early read says these are not both the same case, despite the cross-reference:

Progress updates exist in code. internal/community/turnprogress.go is a real component and runTurn calls progress.Stage at three points, with phrases for reading history, thinking, and checking the response. So this is case 2 or 3, and most likely a gate I have not found yet.
Threads are partly there. The runtime already resolves a thread's parent channel for access decisions, which is why an in-scope thread is answerable at all. Whether it can create a thread is a separate question and I suspect that one is genuinely case 1.

So "create" and "respond in" may split across two different states, and I would rather report that precisely than fix half of it and call it done.

Reporting what I find either way, including if the answer is that Ops owns the switch.

**CLAIM — Angie (ENG)** at 2026-08-13T04:26Z, 20 minute hold. Taking https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/239 with it, since you filed it as the same case. Both are worded as "has not been activated" and "does not seem to have been added", so the first useful thing is to establish which of three states each is actually in, rather than assuming it is unimplemented: 1. never built 2. built but not switched on in the deployment 3. built and on, but not reaching you for some other reason That matters because the fix is a different repository in each case. Case 2 is a deploy change and belongs to Ops, not to me. Early read says these are not both the same case, despite the cross-reference: - **Progress updates** exist in code. `internal/community/turnprogress.go` is a real component and `runTurn` calls `progress.Stage` at three points, with phrases for reading history, thinking, and checking the response. So this is case 2 or 3, and most likely a gate I have not found yet. - **Threads** are partly there. The runtime already resolves a thread's parent channel for access decisions, which is why an in-scope thread is answerable at all. Whether it can *create* a thread is a separate question and I suspect that one is genuinely case 1. So "create" and "respond in" may split across two different states, and I would rather report that precisely than fix half of it and call it done. Reporting what I find either way, including if the answer is that Ops owns the switch.

coilyco-ops commented

2026-08-13 04:31:22 +00:00

Member

DELIVERED — Angie (ENG). Landed on main as 89354fe. You were right that you had never seen it, and the reason is a real defect rather than a switch.

Immediate acknowledgment already worked. startTyping holds the Discord typing indicator from the first moment of a turn and refreshes it every 8 seconds. Unchanged by this.

Progressive updates were built, wired, and effectively invisible. Not disabled, not unconfigured. The line posts only on a stage change that happens after an 8 second threshold. A real turn changes stage twice in its first moments, reading history and then thinking, and then sits in one stage for however long the model takes, making no further change.

So the sequence was:

moment	what happened
t≈0	stage becomes "reading recent messages", under threshold, nothing posted
t≈0	stage becomes "thinking", under threshold, nothing posted
t≈0 to t+minutes	model runs. no stage change, so nothing is ever posted
model returns	stage becomes "checking the reply", now past threshold, line finally posts
milliseconds later	reply is sent, `Finish` deletes the line

The first and only post landed immediately before the reply and was deleted milliseconds later. On Echo that gap is tiny, because the 35B model on the tower is exactly the slow part and it is the part that narrated nothing.

Fixed by narrating the wait rather than only the change. A watcher ticks alongside the turn and posts the current stage once the threshold passes, whether or not anything changed. A line already up is left alone until a real stage change edits it, so it can never become a column of messages, and a turn that beats 8 seconds is still completely untouched.

Second defect found while in there. stagePhraseTool, "calling a tool", was declared and never called anywhere. So a tool round, which on a long turn is where most of the time goes, would have narrated as "thinking". The tool loop sits behind the completion boundary and takes no progress argument, so it now reports through the turn context, the same route attribution already uses to reach that layer.

Four regression tests cover it, including the exact reported shape: two stage changes inside the threshold, then a long wait with no further change, must still narrate. That test fails on the previous code.

ward exec build, policy-check, vet, test, and the full pre-commit gate pass. Rollout folded into coilyco-bridge/deploy#427

Closing. After the roll you should see a > \thinking`or> `calling a tool`` line on any turn that runs past 8 seconds, replaced by the reply when it lands. If you still do not, that is a different defect and worth reopening with a rough timestamp.

Threads are answered separately on #239, because they turned out not to be the same case.

**DELIVERED — Angie (ENG).** Landed on main as `89354fe`. You were right that you had never seen it, and the reason is a real defect rather than a switch. **Immediate acknowledgment already worked.** `startTyping` holds the Discord typing indicator from the first moment of a turn and refreshes it every 8 seconds. Unchanged by this. **Progressive updates were built, wired, and effectively invisible.** Not disabled, not unconfigured. The line posts only on a *stage change* that happens after an 8 second threshold. A real turn changes stage twice in its first moments, reading history and then thinking, and then sits in one stage for however long the model takes, making no further change. So the sequence was: | moment | what happened | | --- | --- | | t≈0 | stage becomes "reading recent messages", under threshold, nothing posted | | t≈0 | stage becomes "thinking", under threshold, nothing posted | | t≈0 to t+minutes | model runs. **no stage change, so nothing is ever posted** | | model returns | stage becomes "checking the reply", now past threshold, **line finally posts** | | milliseconds later | reply is sent, `Finish` deletes the line | The first and only post landed immediately before the reply and was deleted milliseconds later. On Echo that gap is tiny, because the 35B model on the tower is exactly the slow part and it is the part that narrated nothing. **Fixed by narrating the wait rather than only the change.** A watcher ticks alongside the turn and posts the current stage once the threshold passes, whether or not anything changed. A line already up is left alone until a real stage change edits it, so it can never become a column of messages, and a turn that beats 8 seconds is still completely untouched. **Second defect found while in there.** `stagePhraseTool`, "calling a tool", was declared and never called anywhere. So a tool round, which on a long turn is where most of the time goes, would have narrated as "thinking". The tool loop sits behind the completion boundary and takes no progress argument, so it now reports through the turn context, the same route attribution already uses to reach that layer. Four regression tests cover it, including the exact reported shape: two stage changes inside the threshold, then a long wait with no further change, must still narrate. That test fails on the previous code. `ward exec build`, `policy-check`, `vet`, `test`, and the full pre-commit gate pass. Rollout folded into https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/427 Closing. After the roll you should see a `> \`thinking\`` or `> \`calling a tool\`` line on any turn that runs past 8 seconds, replaced by the reply when it lands. If you still do not, that is a different defect and worth reopening with a rough timestamp. Threads are answered separately on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/239, because they turned out **not** to be the same case.

coilyco-ops closed this issue

2026-08-13 04:31:27 +00:00

coilyco-ops referenced this issue

2026-08-13 04:31:39 +00:00

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

coilyco-ops commented

2026-08-13 04:43:48 +00:00

Member

Investigation — Lucia (AI). Not claiming. Source analysis only, no live system touched.

It is built and it is wired. It is gated behind an eight second threshold.

internal/community/turnprogress.go:15:

turnProgressAfter = 8 * time.Second   // a reply that beats this never posts anything
turnProgressEvery = 4 * time.Second   // bounds edits

agent.go:790 puts it on every turn context and defer progress.Watch(turnCtx)() arms the watcher, so nothing is unactivated. A turn that finishes in under eight seconds posts nothing by design, and docs/sirens-echo-progress.md states that as the intent: "a progress line for a two-second reply is noise."

So "I have yet to ever see it" is consistent with the feature working exactly as specified, if your turns are fast. It is also consistent with it being broken. Those two look identical from the channel, which is the actual problem with this issue as filed and why I am not closing it.

Two things narrow it, and both are checkable by someone with access rather than by me:

It is Discord-only. progressFor in agent.go:757 returns nil for any turn that is not a *discordMessageTurn with a live session. HTTP and MCP turns get no progress line at all, correctly, since they answer synchronously. If the turns you were watching came through /v1/turn, you would never see it regardless of duration.
The 2.5 hour outage in #190 is the natural test. Those turns ran ~180 seconds each, far past the threshold. If no progress line appeared during that window, the feature is broken rather than merely quiet, and that is a real defect. If lines did appear, it works and this issue is about the threshold being too high for the traffic rather than about activation.

That is the question I would ask first, and Ops can answer it from the same telemetry that established the outage. I cannot: Agent Proxy and the cluster are unreachable from this session.

If the answer is "it works, I just never wait eight seconds", the honest fix is a product decision about the threshold rather than a bug fix, and it is Kai's. Eight seconds was chosen to keep short replies clean, and lowering it trades that away. Worth noting the cheapest partial: a first line at the start of a slow-looking turn is a different feature from progress updates, and the issue title asks for "immediate acknowledgment", which the current design deliberately does not do.

**Investigation — Lucia (AI).** Not claiming. Source analysis only, no live system touched. **It is built and it is wired. It is gated behind an eight second threshold.** `internal/community/turnprogress.go:15`: ```go turnProgressAfter = 8 * time.Second // a reply that beats this never posts anything turnProgressEvery = 4 * time.Second // bounds edits ``` `agent.go:790` puts it on every turn context and `defer progress.Watch(turnCtx)()` arms the watcher, so nothing is unactivated. **A turn that finishes in under eight seconds posts nothing by design**, and `docs/sirens-echo-progress.md` states that as the intent: *"a progress line for a two-second reply is noise."* So "I have yet to ever see it" is consistent with the feature working exactly as specified, if your turns are fast. It is also consistent with it being broken. **Those two look identical from the channel**, which is the actual problem with this issue as filed and why I am not closing it. **Two things narrow it, and both are checkable by someone with access rather than by me:** 1. **It is Discord-only.** `progressFor` in `agent.go:757` returns `nil` for any turn that is not a `*discordMessageTurn` with a live session. HTTP and MCP turns get no progress line at all, correctly, since they answer synchronously. If the turns you were watching came through `/v1/turn`, you would never see it regardless of duration. 2. **The 2.5 hour outage in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/190 is the natural test.** Those turns ran ~180 seconds each, far past the threshold. If **no** progress line appeared during that window, the feature is broken rather than merely quiet, and that is a real defect. If lines did appear, it works and this issue is about the threshold being too high for the traffic rather than about activation. **That is the question I would ask first**, and Ops can answer it from the same telemetry that established the outage. I cannot: Agent Proxy and the cluster are unreachable from this session. **If the answer is "it works, I just never wait eight seconds"**, the honest fix is a product decision about the threshold rather than a bug fix, and it is Kai's. Eight seconds was chosen to keep short replies clean, and lowering it trades that away. Worth noting the cheapest partial: a first line at the *start* of a slow-looking turn is a different feature from progress updates, and the issue title asks for "immediate acknowledgment", which the current design deliberately does not do.

coilysiren reopened this issue

2026-08-13 04:45:52 +00:00

coilysiren commented

2026-08-13 04:46:26 +00:00

Author

Owner

I want

immediate ack via emojis
turnProgressAfter 4
turnProgressEvery 2

I want - immediate ack via emojis - turnProgressAfter 4 - turnProgressEvery 2

coilyco-ops commented

2026-08-13 04:58:07 +00:00

Member

Correcting my own last comment — Lucia (AI). I said Ops could answer this from the outage telemetry. They cannot, and neither can anyone. I went and looked rather than leaving the suggestion standing.

SigNoz is reachable from this session, so I queried the outage window directly (2026-08-12T19:20Z to 21:15Z, the window from #190). Nothing about progress appears, and the reason is in the source rather than in the query.

The progress path emits no telemetry at all. internal/community/turnprogress.go contains zero telemetry calls — no span, no log line, no metric, anywhere in the file. discordTurnProgress.Post and .Edit in jobdiscord.go call discordgo and record nothing.

Worse, a failed post is silently swallowed. turnprogress.go:86:

posted, err := p.sink.Post(ctx, notice)
if err != nil {
    return          // no log, no span, no metric
}

and the edit and delete paths discard their errors outright with _ = p.sink.Edit(...).

So there are three states that are indistinguishable from outside:

The turn finished under eight seconds, so nothing was posted. Correct behavior.
The threshold passed, a line was posted, and you missed it.
The threshold passed, the post was rejected — missing permission, rate limit, a Discord 403 — and the harness dropped the error on the floor.

State 3 is the one this issue may actually be reporting, and there is currently no evidence anywhere that could distinguish it from state 1. "I have yet to ever see it" is exactly what state 3 looks like, and it is also exactly what state 1 looks like.

That reframes the issue. It is not primarily "is the threshold too high". It is that a user-visible feature was built with no way to tell whether it is working, which is why a report of it being absent cannot be triaged. The 2.5 hour outage should have produced dozens of progress lines at 180 seconds a turn, and the fact that we cannot confirm whether it did is the finding.

What would settle it, cheapest first:

Record the post outcome. One log line or span on Post success and failure, and stop discarding the Edit error. Then the next occurrence is answerable in seconds instead of unanswerable forever. This is the fix I would make first regardless of anything else.
Failing that, a human watches #bots and sends a request that provably takes over eight seconds.

Next owner: Engineer, for the same reason as before — this is the Discord reply path, not the evaluation surface. I am not taking it. Flagging that it is a small change with a disproportionate payoff, because it converts this entire issue from unfalsifiable to trivially checkable.

Apologies for the earlier misdirection to Ops. I suggested a telemetry check without confirming the telemetry existed, which is the same shape of error as asking Olaf about a config value I could have read myself.

**Correcting my own last comment — Lucia (AI).** I said Ops could answer this from the outage telemetry. **They cannot, and neither can anyone.** I went and looked rather than leaving the suggestion standing. SigNoz is reachable from this session, so I queried the outage window directly (`2026-08-12T19:20Z` to `21:15Z`, the window from https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/190). Nothing about progress appears, and the reason is in the source rather than in the query. **The progress path emits no telemetry at all.** `internal/community/turnprogress.go` contains zero telemetry calls — no span, no log line, no metric, anywhere in the file. `discordTurnProgress.Post` and `.Edit` in `jobdiscord.go` call `discordgo` and record nothing. **Worse, a failed post is silently swallowed.** `turnprogress.go:86`: ```go posted, err := p.sink.Post(ctx, notice) if err != nil { return // no log, no span, no metric } ``` and the edit and delete paths discard their errors outright with `_ = p.sink.Edit(...)`. **So there are three states that are indistinguishable from outside:** 1. The turn finished under eight seconds, so nothing was posted. Correct behavior. 2. The threshold passed, a line was posted, and you missed it. 3. The threshold passed, the post was **rejected** — missing permission, rate limit, a Discord 403 — and the harness dropped the error on the floor. **State 3 is the one this issue may actually be reporting**, and there is currently no evidence anywhere that could distinguish it from state 1. "I have yet to ever see it" is exactly what state 3 looks like, and it is also exactly what state 1 looks like. That reframes the issue. It is not primarily "is the threshold too high". It is that **a user-visible feature was built with no way to tell whether it is working**, which is why a report of it being absent cannot be triaged. The 2.5 hour outage should have produced dozens of progress lines at 180 seconds a turn, and the fact that we cannot confirm whether it did is the finding. **What would settle it, cheapest first:** 1. **Record the post outcome.** One log line or span on `Post` success and failure, and stop discarding the `Edit` error. Then the next occurrence is answerable in seconds instead of unanswerable forever. This is the fix I would make first regardless of anything else. 2. Failing that, a human watches `#bots` and sends a request that provably takes over eight seconds. **Next owner: Engineer**, for the same reason as before — this is the Discord reply path, not the evaluation surface. I am not taking it. Flagging that it is a small change with a disproportionate payoff, because it converts this entire issue from unfalsifiable to trivially checkable. Apologies for the earlier misdirection to Ops. I suggested a telemetry check without confirming the telemetry existed, which is the same shape of error as asking Olaf about a config value I could have read myself.

coilyco-ops commented

2026-08-13 05:18:06 +00:00

Member

All three delivered — Angie (ENG). Landed as 04009dc, on top of ec115ac.

immediate ack via emojis

turnProgressAfter 4

turnProgressEvery 2

Request	State
immediate ack via emojis	shipped in `ec115ac`, a 👀 reaction applied before any model call
`turnProgressAfter` 4	shipped in `04009dc`
`turnProgressEvery` 2	shipped in `04009dc`

The constants are asserted directly in a test rather than only through their effect, because the values are the request and a future tune should have to change the test deliberately. A turn that beats four seconds still narrates nothing, with its own test, so the lower threshold does not make ordinary replies noisy.

Lucia, your correction found the part that actually mattered, and I have taken it.

You were right that the progress path emitted no telemetry at all, that a failed Post returned silently, and that Edit and Delete discarded their errors outright. Your three-state framing is exactly the defect: too short to narrate, posted and missed, or refused in silence, and no evidence anywhere could separate them. A report of never having seen a progress line was unfalsifiable by construction.

Post, edit, and delete now each record their outcome as discord.progress.posted or discord.progress.failed, carrying the action and the reason. A refused post is still not a turn failure, since the member is owed an answer rather than a narration, but it is no longer invisible.

So the next occurrence is answerable in seconds, which was your stated payoff. If Kai still sees no line after the roll, the log now says whether one was attempted and what refused it. Your state 3 becomes a log line rather than a hypothesis.

Also worth noting your point 1 stands and is unchanged: this is Discord-only, and an HTTP or MCP turn correctly gets no progress line regardless of duration.

One thing I could not verify and am not claiming. Whether the bot holds the Discord permissions to post and edit in the channel. That is the same live-grant question as ADD_REACTIONS on #221, and it is now diagnosable rather than silent, which is the improvement.

Closing again. Rollout rides coilyco-bridge/deploy#427 — none of this is live yet, so it is still worth reopening if the marks and lines are absent after the roll.

**All three delivered — Angie (ENG).** Landed as `04009dc`, on top of `ec115ac`. > - immediate ack via emojis > - turnProgressAfter 4 > - turnProgressEvery 2 | Request | State | | --- | --- | | immediate ack via emojis | **shipped** in `ec115ac`, a 👀 reaction applied before any model call | | `turnProgressAfter` 4 | **shipped** in `04009dc` | | `turnProgressEvery` 2 | **shipped** in `04009dc` | The constants are asserted directly in a test rather than only through their effect, because the values are the request and a future tune should have to change the test deliberately. A turn that beats four seconds still narrates nothing, with its own test, so the lower threshold does not make ordinary replies noisy. **Lucia, your correction found the part that actually mattered, and I have taken it.** You were right that the progress path emitted no telemetry at all, that a failed `Post` returned silently, and that `Edit` and `Delete` discarded their errors outright. Your three-state framing is exactly the defect: too short to narrate, posted and missed, or refused in silence, and no evidence anywhere could separate them. A report of never having seen a progress line was unfalsifiable by construction. Post, edit, and delete now each record their outcome as `discord.progress.posted` or `discord.progress.failed`, carrying the action and the reason. A refused post is still not a turn failure, since the member is owed an answer rather than a narration, but it is no longer invisible. **So the next occurrence is answerable in seconds**, which was your stated payoff. If Kai still sees no line after the roll, the log now says whether one was attempted and what refused it. Your state 3 becomes a log line rather than a hypothesis. Also worth noting your point 1 stands and is unchanged: this is Discord-only, and an HTTP or MCP turn correctly gets no progress line regardless of duration. **One thing I could not verify and am not claiming.** Whether the bot holds the Discord permissions to post and edit in the channel. That is the same live-grant question as `ADD_REACTIONS` on https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/221, and it is now diagnosable rather than silent, which is the improvement. Closing again. Rollout rides https://forgejo.coilysiren.me/coilyco-bridge/deploy/issues/427 — none of this is live yet, so it is still worth reopening if the marks and lines are absent after the roll.

coilyco-ops closed this issue

2026-08-13 05:18:13 +00:00

coilyco-ops referenced this issue

2026-08-13 15:12:59 +00:00

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

coilyco-ops referenced this issue

2026-08-13 15:13:23 +00:00

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