The summon counter is a floor on the thread case and counts two different units across its legs #1107

New issue

Open

opened 2026-08-22 22:16:18 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-22 22:16:18 +00:00

Member

Filed by Darren (director seat), 2026-08-22. Both raised in review on #1104 and merged unaddressed at 96fe13d, so they get a home rather than sitting on a closed pull request. Neither was a blocker and #992 was worth landing. The counter it shipped is good, and these are the two places it is less exact than it reads.

1. A state-cache miss undercounts the thread case, which is the case members report

notAddressedIn in internal/community/summongate.go reads session.State.Channel and returns the plain not_addressed on a miss:

// Cached state only. A miss reports the plain refusal rather than spending
// a REST call on a message nobody is waiting for.

Declining the REST call is right. The consequence worth naming is that not_addressed_in_thread is a floor rather than a count, and that reason exists specifically because it is the one people report, being #750 rather than a turn that died. So the number a member's complaint gets checked against is the one the miss degrades.

This repository already solved the same problem. internal/community/agent.go carries threads *channelScope, whose own comment says it is there "so a state miss costs one REST lookup per channel rather than one per message. See sirens-echo#750." Same cache, same question, added for the same issue. Consulting it makes the count exact after the first lookup per channel and keeps the per-message cost at zero.

notAddressedIn is a free function today, so this costs a receiver or a lookup passed in.

2. The refusal legs count deliveries while the admit leg counts messages

There are three RecordSummon call sites. The admit one sits behind the duplicate gate and carries the comment "Counted after the duplicate gate, so a redelivery is one summon rather than two." The two refusal sites are in front of it.

So a redelivered non-summoning message is counted twice and a redelivered summon once. The pull request describes the admit counts as giving the refusal rate "a denominator", and a ratio whose halves count different things is the one use this asymmetry breaks.

Either move the refusal counts behind the same gate, or say in docs/sirens-echo-admission.md which leg counts what, so the next reader of a ratio knows what they have.

Done when

A non-summoning message in a thread is counted as not_addressed_in_thread even when the channel is not in cached state, and the admit and refusal legs count the same unit, or the page says plainly that they do not.

#992 - the issue this shipped for, closed
#1104 - where it landed, merged at 96fe13d
#750 - the behaviour the thread reason exists to make visible

**Filed by Darren (director seat), 2026-08-22.** Both raised in review on #1104 and merged unaddressed at `96fe13d`, so they get a home rather than sitting on a closed pull request. Neither was a blocker and #992 was worth landing. The counter it shipped is good, and these are the two places it is less exact than it reads. ## 1. A state-cache miss undercounts the thread case, which is the case members report `notAddressedIn` in `internal/community/summongate.go` reads `session.State.Channel` and returns the plain `not_addressed` on a miss: ```go // Cached state only. A miss reports the plain refusal rather than spending // a REST call on a message nobody is waiting for. ``` Declining the REST call is right. The consequence worth naming is that **`not_addressed_in_thread` is a floor rather than a count**, and that reason exists specifically because it is the one people report, being #750 rather than a turn that died. So the number a member's complaint gets checked against is the one the miss degrades. **This repository already solved the same problem.** `internal/community/agent.go` carries `threads *channelScope`, whose own comment says it is there "so a state miss costs one REST lookup per channel rather than one per message. See sirens-echo#750." Same cache, same question, added for the same issue. Consulting it makes the count exact after the first lookup per channel and keeps the per-message cost at zero. `notAddressedIn` is a free function today, so this costs a receiver or a lookup passed in. ## 2. The refusal legs count deliveries while the admit leg counts messages There are three `RecordSummon` call sites. The admit one sits behind the duplicate gate and carries the comment "Counted after the duplicate gate, so a redelivery is one summon rather than two." **The two refusal sites are in front of it.** So a redelivered non-summoning message is counted twice and a redelivered summon once. The pull request describes the admit counts as giving the refusal rate "a denominator", and a ratio whose halves count different things is the one use this asymmetry breaks. Either move the refusal counts behind the same gate, or say in `docs/sirens-echo-admission.md` which leg counts what, so the next reader of a ratio knows what they have. ## Done when A non-summoning message in a thread is counted as `not_addressed_in_thread` even when the channel is not in cached state, and the admit and refusal legs count the same unit, or the page says plainly that they do not. ## Related * #992 - the issue this shipped for, closed * #1104 - where it landed, merged at `96fe13d` * #750 - the behaviour the thread reason exists to make visible

coilyco-ops added the

labels

2026-08-22 22:16:18 +00:00

coilyco-ops referenced this issue

2026-08-22 23:16:42 +00:00

Lane: headless engineer burn-down in sirens-echo, 19 issues at P1 and P2, led by the slot pool the load test already indicted #1095

coilyco-ops referenced this issue

2026-08-22 23:51:54 +00:00