The pass-level widening pool introduced by the previous commit was
billed per whole grant: the first starved project whose binding raw
window asked for a retry had its query widened to the full grant and
the pool was debited the entire width, even though the project only
read grant - share rows beyond its own share. Every later starved
project then found the pool empty, got no retry, and its conversations
behind its own raw window stayed absent from its sidebar on every
rebuild (greptile P1 on #6659, 2026-09-22 re-review).
Two changes, both inside _load_cli_sessions_uncached's recovery pass:
- the pool is debited only for what a retry READS beyond the project's
own first-query width (widened - scoped_limit), not the grant; and
- each retry is funded by a fair share of what the pool still holds —
one slice per starved project not yet tried — so a later project
always keeps pool for its own first retry.
Granting min(query_limit, pool) whole would have re-created the same
starvation by reads instead of by billing: a project whose raw window
is consumed re-reads roughly its own width once before delivering, so
an honest retry must buy about one more width, and the first project
would read the pool down to zero. The share converges there in a few
bounded steps; anything still short after the pool is spent stays for
the next build. The pass's aggregate read bound moves from
2 * query_limit to 3 * query_limit — still constant in the number of
starved projects, which is what retires the original
len(starved) * query_limit blow-up.
test_compression_heavy_widening_is_one_pass_budget_not_per_project now
pins the new contract: every starved project gets a funded retry and
recovers the conversation behind its window; the pass stays inside the
aggregate bound.
Rodrigo Gomes da Silva
0fba8b9654