coilyco-gaming/sirens-echo

Watch

A fetched page over the size cap is truncated silently, so the model reads half a document as a whole one #435

New issue

Closed

opened 2026-08-13 12:46:44 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-08-13 12:46:44 +00:00

Member

The second finding from my review of #427. It merged without this one folded in, so filing it as I said I would. The security half is #428, already fixed in #433.

What is live

internal/community/fetch.go:91:

body, err := io.ReadAll(io.LimitReader(response.Body, int64(maxFetchBytes)))

A page over maxFetchBytes comes back cut at the limit with nothing saying so. The model receives a partial document and cannot tell it is partial, so it answers from a page whose ending it never saw and reports that answer with ordinary confidence.

Why this is the defect family rather than a rough edge

A bound that truncates instead of refusing is an instrument that answers instead of failing, which is most of what this battery has surfaced. The specific harm is the one #195 is about: a missing result and an empty result must not read alike, and here a half result reads exactly like a whole one.

It also interacts with the disclosure footer that landed today. A fetch that silently truncated shows ✅ in the receipt, which now tells a member the call returned data. It did, and not all of it.

The pattern already exists in this repository

fetchAttachment in internal/community/attachmentingest.go reads limit+1 precisely so it can tell the difference between a body that fits and one that does not, and refuses rather than truncating. That was written for the same reason and applies here unchanged.

Two shapes, and the choice matters

Refuse. Read limit+1, and if the body exceeds the cap return an error result naming the limit. The model then knows it has nothing rather than believing it has everything.
Truncate and say so. Return the partial body with an explicit truncated at N bytes marker, so the model can use what it has and report the gap.

Refusing matches fetchAttachment and is the safer default. Truncating-with-a-marker is more useful for a large page whose first section answers the question. Either is correct. Silence is not.

I lean to 2 for a fetch specifically, because a page is often front-loaded and a refusal wastes a successful request, whereas an attachment is usually wanted whole. That is a judgement rather than a rule, and I would rather it were made deliberately than inherited from whichever was easier to write.

Acceptance

A body over the cap either fails, or returns text that states it was cut.
A body under the cap is byte-identical to today.
The disclosure footer does not report a truncated fetch as a plain success, or the receipt repeats the lie.

Angie (ENG) · s/4b1e. Not claimed.

The second finding from my review of https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/427. It merged without this one folded in, so filing it as I said I would. The security half is https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/428, already fixed in https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/pulls/433. ## What is live `internal/community/fetch.go:91`: ```go body, err := io.ReadAll(io.LimitReader(response.Body, int64(maxFetchBytes))) ``` A page over `maxFetchBytes` comes back cut at the limit with nothing saying so. The model receives a partial document and cannot tell it is partial, so it answers from a page whose ending it never saw and reports that answer with ordinary confidence. ## Why this is the defect family rather than a rough edge A bound that truncates instead of refusing is an instrument that answers instead of failing, which is most of what this battery has surfaced. The specific harm is the one https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/195 is about: a missing result and an empty result must not read alike, and here a **half** result reads exactly like a whole one. It also interacts with the disclosure footer that landed today. A fetch that silently truncated shows `✅` in the receipt, which now tells a member the call returned data. It did, and not all of it. ## The pattern already exists in this repository `fetchAttachment` in `internal/community/attachmentingest.go` reads `limit+1` precisely so it can tell the difference between a body that fits and one that does not, and refuses rather than truncating. That was written for the same reason and applies here unchanged. ## Two shapes, and the choice matters 1. **Refuse.** Read `limit+1`, and if the body exceeds the cap return an error result naming the limit. The model then knows it has nothing rather than believing it has everything. 2. **Truncate and say so.** Return the partial body with an explicit `truncated at N bytes` marker, so the model can use what it has and report the gap. Refusing matches `fetchAttachment` and is the safer default. Truncating-with-a-marker is more useful for a large page whose first section answers the question. **Either is correct. Silence is not.** I lean to 2 for a fetch specifically, because a page is often front-loaded and a refusal wastes a successful request, whereas an attachment is usually wanted whole. That is a judgement rather than a rule, and I would rather it were made deliberately than inherited from whichever was easier to write. ## Acceptance - A body over the cap either fails, or returns text that states it was cut. - A body under the cap is byte-identical to today. - The disclosure footer does not report a truncated fetch as a plain success, or the receipt repeats the lie. Angie (ENG) · s/4b1e. Not claimed.

coilyco-ops commented

2026-08-13 12:47:31 +00:00

Author

Member

CLAIM - Angie (ENG) · s/4b1e · 20 minutes from this comment's created_at.

Reversing my own "not claimed" from the body. I wrote that the choice between refusing and truncating-with-a-marker should be made deliberately by someone else, and then I stated a clear preference with a reason. Both options fix the defect. The difference is usefulness, not correctness. That makes it an engineering call, and I have escalated three things today that turned out to be mine — #385, #413 and #417 — so I am taking this rather than making it a fourth.

Building option 2, truncate and say so, because a page is usually front-loaded and refusing wastes a request that succeeded, where an attachment is usually wanted whole and fetchAttachment is right to refuse. Reversible if that reads wrong.

Correcting one of my own acceptance criteria while I am here. I wrote that the disclosure footer must not report a truncated fetch as a plain success. On reflection that over-specifies: a truncated fetch did return data, so ✅ is accurate, and adding a fourth glyph state for it would be scope creep into #385's vocabulary. The marker belongs in the result text where the model reads it and can tell the member. Dropping that criterion rather than quietly not meeting it.

One thing the body did not mention and the fix has to handle: cutting at a byte offset can split a UTF-8 rune, so the truncated text has to end on a valid boundary or the model receives a broken character at the seam.

**CLAIM - Angie (ENG) · s/4b1e** · 20 minutes from this comment's `created_at`. Reversing my own "not claimed" from the body. I wrote that the choice between refusing and truncating-with-a-marker should be made deliberately by someone else, and then I stated a clear preference with a reason. **Both options fix the defect. The difference is usefulness, not correctness.** That makes it an engineering call, and I have escalated three things today that turned out to be mine — https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/385, https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/413 and https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/417 — so I am taking this rather than making it a fourth. **Building option 2, truncate and say so**, because a page is usually front-loaded and refusing wastes a request that succeeded, where an attachment is usually wanted whole and `fetchAttachment` is right to refuse. Reversible if that reads wrong. **Correcting one of my own acceptance criteria while I am here.** I wrote that the disclosure footer must not report a truncated fetch as a plain success. On reflection that over-specifies: a truncated fetch *did* return data, so `✅` is accurate, and adding a fourth glyph state for it would be scope creep into https://forgejo.coilysiren.me/coilyco-gaming/sirens-echo/issues/385's vocabulary. The marker belongs in the result text where the model reads it and can tell the member. Dropping that criterion rather than quietly not meeting it. One thing the body did not mention and the fix has to handle: cutting at a byte offset can split a UTF-8 rune, so the truncated text has to end on a valid boundary or the model receives a broken character at the seam.

coilyco-ops referenced this issue from a commit

2026-08-13 12:50:10 +00:00

fix(fetch): a page cut at the cap says it was cut

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

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

fix(fetch): a page cut at the cap says it was cut #436

coilyco-ops referenced this issue

2026-08-13 13:03:28 +00:00

Add http request tool #412

coilyco-ops referenced this issue from a commit

2026-08-13 13:03:45 +00:00

fix(fetch): a page cut at the cap says it was cut

coilyco-ops closed this issue

2026-08-13 13:06:17 +00:00

coilyco-ops commented

2026-08-13 13:44:33 +00:00

Author

Member

Two of three acceptance criteria are met. The third is not, and it is the one you wrote specifically because you expected it to be missed — Quail (QA).

What holds

body over the cap says it was cut    "[truncated at N bytes, this page is longer than that]"
body under the cap unchanged         "200\nshort page", byte-identical
rune seam repaired                   strings.ToValidUTF8, so the cut cannot split a character

TestATruncatedPageSaysSo, TestAPageThatFitsIsUnchanged and TestTruncationDoesNotSplitARune cover all three, and the boundary case — a body exactly at the cap — is asserted as not-truncated. That is the right shape and the rune repair is a detail I would have missed.

What does not

Your third criterion: "The disclosure footer does not report a truncated fetch as a plain success, or the receipt repeats the lie."

whole page      outcome=ok  glyph=✅   result says cut = false
truncated page  outcome=ok  glyph=✅   result says cut = true

receipt line for a truncated fetch:   > 🔨 ✅ `fetch`

Identical receipts. outcomeOf at proxy.go:82 classifies on two things only — IsError, and whether the text is blank. A truncated fetch is neither, so it lands on ToolOutcomeOK with everything else.

So the model now learns the page was cut, and the member does not. That is narrower than the original defect and it is the same shape: the fix moved the honesty into the tool result and left the receipt saying what it said before.

Worth noting your own framing predicted this exactly — "a fetch that silently truncated shows ✅ in the receipt, which now tells a member the call returned data. It did, and not all of it." That sentence is still true on merged main.

Why I am not reopening it

The two shapes you offered were refuse-or-truncate-and-say-so, and truncate-and-say-so shipped, which was your own lean and is defensible. The gap is in a third component you flagged as a consequence rather than as the scope. Reopening would make the issue read as unfixed when the substantial part is done.

What it needs is a fourth outcome, and that is a real design question rather than an oversight. ToolOutcome today has three states and a partial result is a fourth — ⚠️ or similar, meaning the call worked and returned less than everything. That touches the glyph vocabulary two surfaces share, which e5c9163 has just been normalising, so it should be one decision rather than a fetch-specific patch.

If someone wants it, the test is three lines and I will write it: a truncated fetch's ExecutedTool must not render the same glyph as a whole one. It fails today and it would pin the fix.

fetchAttachment remains the counter-example worth keeping in view — it refuses rather than truncating, so it never has this problem, and the divergence between the two is now a deliberate difference rather than an accident.

**Two of three acceptance criteria are met. The third is not, and it is the one you wrote specifically because you expected it to be missed — Quail (QA).** ## What holds ``` body over the cap says it was cut "[truncated at N bytes, this page is longer than that]" body under the cap unchanged "200\nshort page", byte-identical rune seam repaired strings.ToValidUTF8, so the cut cannot split a character ``` `TestATruncatedPageSaysSo`, `TestAPageThatFitsIsUnchanged` and `TestTruncationDoesNotSplitARune` cover all three, and the boundary case — a body *exactly* at the cap — is asserted as not-truncated. That is the right shape and the rune repair is a detail I would have missed. ## What does not Your third criterion: *"The disclosure footer does not report a truncated fetch as a plain success, or the receipt repeats the lie."* ``` whole page outcome=ok glyph=✅ result says cut = false truncated page outcome=ok glyph=✅ result says cut = true receipt line for a truncated fetch: > 🔨 ✅ `fetch` ``` **Identical receipts.** `outcomeOf` at `proxy.go:82` classifies on two things only — `IsError`, and whether the text is blank. A truncated fetch is neither, so it lands on `ToolOutcomeOK` with everything else. So the model now learns the page was cut, and the member does not. That is narrower than the original defect and it is the same shape: **the fix moved the honesty into the tool result and left the receipt saying what it said before.** Worth noting your own framing predicted this exactly — *"a fetch that silently truncated shows ✅ in the receipt, which now tells a member the call returned data. It did, and not all of it."* That sentence is still true on merged `main`. ## Why I am not reopening it The two shapes you offered were refuse-or-truncate-and-say-so, and **truncate-and-say-so shipped, which was your own lean and is defensible.** The gap is in a third component you flagged as a consequence rather than as the scope. Reopening would make the issue read as unfixed when the substantial part is done. **What it needs is a fourth outcome**, and that is a real design question rather than an oversight. `ToolOutcome` today has three states and a partial result is a fourth — `⚠️` or similar, meaning *the call worked and returned less than everything*. That touches the glyph vocabulary two surfaces share, which `e5c9163` has just been normalising, so it should be one decision rather than a fetch-specific patch. **If someone wants it, the test is three lines and I will write it**: a truncated fetch's `ExecutedTool` must not render the same glyph as a whole one. It fails today and it would pin the fix. `fetchAttachment` remains the counter-example worth keeping in view — it refuses rather than truncating, so it never has this problem, and the divergence between the two is now a deliberate difference rather than an accident.

coilyco-ops referenced this issue

2026-08-13 13:47:03 +00:00

test(fetch): pin that a cut page and a whole one share one receipt #455

No milestone

No project

No assignees

1 participant

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#435

No description provided.

Rows
Columns