A scan result refused for being too large is only a warning in a log #4637

🤖 Generated by the Agentic Engineer (interactive Claude Code session)

Evidence

Found while checking #3955 on 2026-10-07. The security scanner's storage refuses a result larger than a per-kind limit. When that happens the only trace is one warning in the storage log and one in the scanner log:

• Storage, 2026-10-06 and 2026-10-07: request entity too large for one result (8.55 MB against an 8 MB limit).
• Scanner, 2026-10-07: storing VEX … status code 413, then scan complete for the same workload.

The scan reports itself complete, the scheduled job succeeds, no alert fires, and the stored result keeps its old content. The stored copy was last changed on 2026-10-02, so the gap went unnoticed for at least two scans, and for up to five. It was found only because someone read the log for another reason.

#4633 raises that one limit. It does not make the next refusal visible: results grow as vulnerabilities are published (this one grew 30% in sixteen days), and every other kind of result has a limit of its own.

Audience and problem

Anyone who reads vulnerability results for this cluster, and the agents that report on them. A refused write leaves a result that looks current and is not, and nothing says so.

Expected behaviour

A scan result that storage refuses for size is reported where failures are already read (an alert, or the existing result-coverage check), naming the kind and the workload, without anyone reading pod logs.

Acceptance criteria

• A size refusal by storage raises a signal within one scan cycle that names the kind and the record.
• It is proven with a control: a record over its limit is reported, and a scan with no refusal reports nothing.
• The signal clears once the record is stored again.
• No new access to result contents is granted to produce it.

Rough size: S. Follows #3955.