The coverage banner gives one reason for three different causes, and for a failed review call the
reason it gives is wrong.
When a batch fails all its retries, FindingPipeline calls plan.recordUncoveredFiles(...), which
lands in BudgetPlan.runtimeUncoveredFiles(). BudgetPlan.effectiveOmittedFiles() merges that list
into the planned omissions, and VerdictBuilder builds TruncationDetail.omittedFileNames from
withoutNames(plan.effectiveOmittedFiles(), ceilingSkipped). ReviewResult.coverageGapClause then
renders every name in it as withheld
because the diff exceeded the review budget
The same review's summary overview separately says of those files
(not reviewed — the review call for it did not complete; treated as uncovered)
so the two surfaces give contradictory reasons for the same file, and the banner's implied remedy —
raise the input budget — does not apply to a call that failed.
The spend-ceiling class already carries its own reason (#524, #530) and the response-cut class
carries its own (#523). Runtime call failure needs the same treatment: either its own clause, or a
clause that does not name budget exhaustion when that is not the cause.
Related: #628 covers the same wrong clause reached by a different route, a file GitHub reported with
changes but no patch text. A fix that gives each cause its own reason would close both.
Surfaced by the bot's review of the v0.6.0 release PR (#532).
The coverage banner gives one reason for three different causes, and for a failed review call the
reason it gives is wrong.
When a batch fails all its retries,
FindingPipelinecallsplan.recordUncoveredFiles(...), whichlands in
BudgetPlan.runtimeUncoveredFiles().BudgetPlan.effectiveOmittedFiles()merges that listinto the planned omissions, and
VerdictBuilderbuildsTruncationDetail.omittedFileNamesfromwithoutNames(plan.effectiveOmittedFiles(), ceilingSkipped).ReviewResult.coverageGapClausethenrenders every name in it as withheld
The same review's summary overview separately says of those files
so the two surfaces give contradictory reasons for the same file, and the banner's implied remedy —
raise the input budget — does not apply to a call that failed.
The spend-ceiling class already carries its own reason (#524, #530) and the response-cut class
carries its own (#523). Runtime call failure needs the same treatment: either its own clause, or a
clause that does not name budget exhaustion when that is not the cause.
Related: #628 covers the same wrong clause reached by a different route, a file GitHub reported with
changes but no patch text. A fix that gives each cause its own reason would close both.
Surfaced by the bot's review of the v0.6.0 release PR (#532).