scratch_read returns whole files to a consumer that holds a fraction of one #1113

New issue

Closed

opened 2026-08-22 22:36:41 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-08-22 22:36:41 +00:00

Member

Split out of #940, whose first defect is broader than the half this repository owns.

scratch_read bounds at maxScratchFileBytes (256 KB, the write limit) rather than at the tool-result budget the consumer actually holds. Measured on sirens-deep-owl-glass, 2026-08-18: scratch_read returned 53,696 bytes with 37,312 dropped against limit_bytes: 16384. The whole round trip was spent to throw 70% of it away, and the model then spent a further round on the spill file for content it should have had first time.

scratch_search was already fixed by 3f3d528 on the day #940 was filed, which is why only the read half remains.

What it should do

Return what fits and say where it stopped, with an offset that continues from there. Refusing the read outright is the smaller change and the wrong one: the agent writes files larger than one tool result and has to be able to read them back.

Acceptance

A file larger than the result budget comes back bounded, on a line boundary and never mid-rune.
The piece says how long the file is and what offset continues it.
Reading from the reported offsets reassembles the file exactly.
A short file is returned untouched, with no boundary note that would read as a truncation that did not happen.

Not this issue

The rest of #940 stays there: the MCP-side results (list_channel-message, the forgejo list_* family) are their servers' to bound, and the fetch_url half is separate.

Refs #940

Split out of #940, whose first defect is broader than the half this repository owns. `scratch_read` bounds at `maxScratchFileBytes` (256 KB, the write limit) rather than at the tool-result budget the consumer actually holds. Measured on `sirens-deep-owl-glass`, 2026-08-18: `scratch_read` returned **53,696 bytes with 37,312 dropped** against `limit_bytes: 16384`. The whole round trip was spent to throw 70% of it away, and the model then spent a further round on the spill file for content it should have had first time. `scratch_search` was already fixed by `3f3d528` on the day #940 was filed, which is why only the read half remains. ## What it should do Return what fits and say where it stopped, with an offset that continues from there. **Refusing the read outright is the smaller change and the wrong one**: the agent writes files larger than one tool result and has to be able to read them back. ## Acceptance * A file larger than the result budget comes back bounded, on a line boundary and never mid-rune. * The piece says how long the file is and what offset continues it. * Reading from the reported offsets reassembles the file exactly. * A short file is returned untouched, with no boundary note that would read as a truncation that did not happen. ## Not this issue The rest of #940 stays there: the MCP-side results (`list_channel-message`, the forgejo `list_*` family) are their servers' to bound, and the `fetch_url` half is separate. Refs #940

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

2026-08-22 22:36:58 +00:00

fix(scratch): bound a read at the file, not after it has crossed #1114

coilyco-ops referenced this issue

2026-08-22 22:37:15 +00:00

Tool results are 87% discarded after the fact, and fetch_url burns rounds on hosts the allowlist was always going to refuse #940

coilyco-ops referenced this issue

2026-08-22 22:38:50 +00:00

fix(scratch): bound a read at the file, not after it has crossed #1114

coilyco-ops referenced this issue

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

Tool results are 87% discarded after the fact, and fetch_url burns rounds on hosts the allowlist was always going to refuse #940