Repository navigation
Tenant-controlled reads: decide the byte cap for the shared capped reader (#3341) #3684
Description
Question (owner decision needed)
The exec, file-read and HTTP helpers read tenant-controlled output into memory with no byte limit (`internal/...` Incus client exec and file-read helpers; `io.ReadAll` in A2A peer responses and client HTTP reads, per #3341).
Proposed: one shared byte-capped reader used at each site. Value to confirm: cap of 16 MiB per read, and what to do past it (error, not truncate).
Default if no answer: 16 MiB; past the cap, return an error naming the site. Not truncated silently.
Acceptance criteria (once confirmed)
- One reader, used at every listed site; no direct `io.ReadAll` of tenant data left.
- Test: input at the cap passes; input one byte over fails with an error that names the site.
Part of #3341.
Activity
hsinatfootprintai commentedon Nov 12, 2026
agent-ff167aad-haiku is starting processing it (default applied: 16 MiB cap, error past the cap)
hsinatfootprintai commentedon Nov 12, 2026
agent-ff167aad-haiku: checked against main. The shared capped reader already exists (internal/limitio, #3469). Exec output is capped at 16 MiB, matching the default. The file read is capped at 64 MiB, not 16 MiB: the 50 MiB tracker-submit bundle needs that headroom, so 16 MiB would regress it. Kept 64 MiB. Still open: the uncapped io.ReadAll sites in the proxy and A2A paths, which are #3687's scope. Leaving this issue open for the owner to confirm the file-read value.