Repository navigation
Should a cache-served list aggregate clear its malformed report? #2021
Description
Split out of the round-10 review discussion on #2016 (issue #1909), where it was deliberately left undecided rather than changed silently.
The question
listAllSalvaging clears the malformed report on every success — including a success served from cache. So a report can disappear on a refresh that did no network work at all.
Why it is arguable in both directions
Clearing is defensible, and is the behavior on v2/main today: a cache-served aggregate is a strict-valid list. Every entry in it parsed, so there is nothing malformed in what is being rendered, and a report left standing would describe a list version the user is no longer looking at.
Keeping it is also defensible: the user asked for a refresh, no network exchange occurred, and a finding they had not yet acted on vanished. From the outside that looks like the problem went away, when in fact nothing was re-checked.
Why it is not part of #1909
This is cache-interaction semantics, not salvage. The salvage path's own question — which exchange owns the tools/list report — was settled in round 10 of #2016 and the reasoning is written down there:
- a failed strict aggregate runs salvage, and salvage writes the report itself;
- a successful strict aggregate means every entry parsed, so the rendered list contains no malformed entries.
Those are the only two cases, which is what retired the exclusion scan's publish. The cache question sits one layer up: not who writes the report, but whether a cache hit should count as the kind of success that clears one.
Disposition
No change for now — the current clear-on-every-success behavior ships with #1909. This issue exists so the question is tracked rather than lost in a PR comment thread.
If it is taken up, worth settling first: whether "refresh produced no network exchange" should be visible in the UI at all, since that is the underlying thing a stale-but-cleared report hides. That may be the better fix, and it would make this question moot.
Cross-reference: the round-10 mirror comment on #2016 has the full reasoning, including the round-9 position that was reversed.
Activity
cliffhall commentedon Aug 16, 2026
Closing as decided rather than leaving it open.
The behavior stands: a cache-served aggregate clears its malformed report, the same as any other success. The justification is the one already in the code — a cache hit returns a strict-valid list, every entry in it parsed, so there is nothing malformed in what is being rendered, and a report left standing would describe a list version the user is no longer looking at.
Filing this as an open question was itself a choice, and a worse one than making the call: it left the shipped behavior looking provisional when it is in fact the reasoned default, and parked a decision in the backlog that nobody was going to return to with better information than we have now.
If the underlying concern resurfaces — a user acting on a finding that vanished on a refresh which did no network work — the better fix is to surface "this refresh produced no network exchange" in the UI, not to keep stale reports alive. That would be a new issue with a real user-facing symptom behind it.
Full reasoning, including the round-9 position that was reversed, is in the round-10 mirror comment on #2016.