Progress posting costs 12 Discord writes for one reply, roughly one edit every 16 seconds #934

New issue

Closed

opened 2026-08-18 01:30:59 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-08-18 01:30:59 +00:00

Member

Filed by Olaf (ops seat) from the 2026-08-18 owl.glass incident review. Split out of #932.

What happens

One turn on sirens-deep-owl-glass, trace db9528828e4905992a04c3d1e7f58a74, 00:47:42 to 00:50:46:

00:47:58  discord.progress.posted  action: post
00:48:24  discord.progress.posted  action: edit
00:48:30  discord.progress.posted  action: edit
00:48:46  discord.progress.posted  action: edit
00:49:02  discord.progress.posted  action: edit
00:49:18  discord.progress.posted  action: edit
00:49:34  discord.progress.posted  action: edit
00:49:50  discord.progress.posted  action: edit
00:50:06  discord.progress.posted  action: edit
00:50:22  discord.progress.posted  action: edit
00:50:38  discord.progress.posted  action: edit
00:50:46  discord.progress.posted  action: delete

1 post, 10 edits, 1 delete = 12 Discord write operations to deliver one 1,269-byte reply. The edits land on a roughly 16-second cadence for as long as the turn runs.

Across the wider burst, 16 discord.progress.posted events against 5 turn.reply.delivered.

Why it matters

Rate limit exposure. Discord write budget is shared across every channel this identity serves, and both Sirens lanes currently run on one bot token (/sirens-deep/discord-bot-token, see coilyco-bridge/deploy#649). A slow turn in one guild spends the allowance for the other.
It reads as thrashing. On a public recording, a message editing itself eleven times over three minutes communicates "stuck" rather than "working", which is the opposite of what a progress indicator is for.
It scales with the bug, not the work. The edit count is a function of turn duration. While community.turn p50 sits at 32.9s and p99 on the 180s ceiling, this multiplies every latency problem into Discord API pressure.

Shape of a fix

The cadence is the wrong control. Some options, not exclusive:

Back off. Edit at increasing intervals rather than a fixed ~16s, so a long turn does not cost proportionally more writes.
Edit on state change, not on a timer. An edit that carries no new information is pure cost.
Cap total edits per turn, then stop updating and let the final reply speak.

Worth pairing with the latency work in #932 rather than tuned in isolation, since a lane at 8s per turn barely posts progress at all.

Done when

A single turn cannot spend more than a small bounded number of Discord writes on progress, independent of how long it runs.

#932 - the incident review this came from
coilyco-bridge/deploy#649 - the shared bot identity that makes the rate limit cross-lane

**Filed by Olaf (ops seat)** from the 2026-08-18 owl.glass incident review. Split out of #932. ## What happens One turn on `sirens-deep-owl-glass`, trace `db9528828e4905992a04c3d1e7f58a74`, 00:47:42 to 00:50:46: ``` 00:47:58 discord.progress.posted action: post 00:48:24 discord.progress.posted action: edit 00:48:30 discord.progress.posted action: edit 00:48:46 discord.progress.posted action: edit 00:49:02 discord.progress.posted action: edit 00:49:18 discord.progress.posted action: edit 00:49:34 discord.progress.posted action: edit 00:49:50 discord.progress.posted action: edit 00:50:06 discord.progress.posted action: edit 00:50:22 discord.progress.posted action: edit 00:50:38 discord.progress.posted action: edit 00:50:46 discord.progress.posted action: delete ``` **1 post, 10 edits, 1 delete = 12 Discord write operations to deliver one 1,269-byte reply.** The edits land on a roughly 16-second cadence for as long as the turn runs. Across the wider burst, 16 `discord.progress.posted` events against 5 `turn.reply.delivered`. ## Why it matters * **Rate limit exposure.** Discord write budget is shared across every channel this identity serves, and both Sirens lanes currently run on one bot token (`/sirens-deep/discord-bot-token`, see coilyco-bridge/deploy#649). A slow turn in one guild spends the allowance for the other. * **It reads as thrashing.** On a public recording, a message editing itself eleven times over three minutes communicates "stuck" rather than "working", which is the opposite of what a progress indicator is for. * **It scales with the bug, not the work.** The edit count is a function of turn duration. While `community.turn` p50 sits at 32.9s and p99 on the 180s ceiling, this multiplies every latency problem into Discord API pressure. ## Shape of a fix The cadence is the wrong control. Some options, not exclusive: * **Back off.** Edit at increasing intervals rather than a fixed ~16s, so a long turn does not cost proportionally more writes. * **Edit on state change, not on a timer.** An edit that carries no new information is pure cost. * **Cap total edits per turn**, then stop updating and let the final reply speak. Worth pairing with the latency work in #932 rather than tuned in isolation, since a lane at 8s per turn barely posts progress at all. ## Done when A single turn cannot spend more than a small bounded number of Discord writes on progress, independent of how long it runs. ## Related * #932 - the incident review this came from * coilyco-bridge/deploy#649 - the shared bot identity that makes the rate limit cross-lane

coilyco-ops added the

labels

2026-08-18 01:30:59 +00:00

coilyco-ops commented

2026-08-18 15:11:49 +00:00

Author

Member

Olaf (ops seat), 2026-08-18. Correcting one premise in the filing above. The measured finding stands, the rationale under the first bullet does not.

Rate limit exposure. Discord write budget is shared across every channel this identity serves, and both Sirens lanes currently run on one bot token (/sirens-deep/discord-bot-token, see coilyco-bridge/deploy#649).

That is no longer true. coilyco-bridge/deploy#651 separated the applications. The Dowel lane runs a distinct Discord application reading /sirens-dowel/discord-bot-token, installed in owl.glass and in no other guild. Verified in sirens-dowel-values.yaml:27 and sirens-dowel-discord-mcp-values.yaml:35 on main.

So the cross-lane spend is gone: a slow turn in owl.glass no longer eats Deep's allowance in Sirens, and the reverse. The write budget is now per-lane rather than shared.

What survives unchanged, and is the actual reason to fix this:

12 Discord writes to deliver one 1,269-byte reply is expensive against a single lane's own budget, not just a shared one.
It reads as thrashing on a public recording. A message editing itself eleven times over three minutes says "stuck". That argument was never about rate limits and is the stronger one for the August 19 stream.
The edit count still scales with turn duration rather than with work done.

Recording rather than retitling. The trace, the counts, and the shape of the fix are all still good.

Related: coilyco-bridge/deploy#661 retires the same shared-identity claim where it survived in the guardfile and the deploy README, which is where a model could read it as ground truth.

**Olaf (ops seat), 2026-08-18.** Correcting one premise in the filing above. The measured finding stands, the rationale under the first bullet does not. > **Rate limit exposure.** Discord write budget is shared across every channel this identity serves, and both Sirens lanes currently run on one bot token (`/sirens-deep/discord-bot-token`, see coilyco-bridge/deploy#649). **That is no longer true.** coilyco-bridge/deploy#651 separated the applications. The Dowel lane runs a distinct Discord application reading `/sirens-dowel/discord-bot-token`, installed in owl.glass and in no other guild. Verified in `sirens-dowel-values.yaml:27` and `sirens-dowel-discord-mcp-values.yaml:35` on `main`. So the cross-lane spend is gone: a slow turn in owl.glass no longer eats Deep's allowance in Sirens, and the reverse. **The write budget is now per-lane rather than shared.** What survives unchanged, and is the actual reason to fix this: * **12 Discord writes to deliver one 1,269-byte reply** is expensive against a single lane's own budget, not just a shared one. * **It reads as thrashing on a public recording.** A message editing itself eleven times over three minutes says "stuck". That argument was never about rate limits and is the stronger one for the August 19 stream. * **The edit count still scales with turn duration rather than with work done.** Recording rather than retitling. The trace, the counts, and the shape of the fix are all still good. Related: coilyco-bridge/deploy#661 retires the same shared-identity claim where it survived in the guardfile and the deploy README, which is where a model could read it as ground truth.

coilyco-ops referenced this issue from a commit

2026-08-19 02:11:29 +00:00

fix(progress): back the wait narration off instead of editing every beat

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

2026-08-19 02:11:57 +00:00

fix(progress): back the wait narration off instead of editing every beat #1021