Greptile P1 on #6659: the retry that follows a binding scoped raw window jumped
straight to the global `query_limit`, and every starved project got it in turn.
`remaining` bounds a project's FIRST scoped query, but the widening was not
bounded by the pass at all, so a build scanned len(starved) * query_limit —
an order of magnitude past PROJECT_ASSIGNED_CLI_SCAN_CEILING on a profile with
ten compression-heavy projects, and growing with the number of them.
The widening now comes out of a single pass-level pool of `query_limit`, charged
the full width of each retry, so the scoped reading of a build is capped at
2 * query_limit however many projects are starved. When the pool cannot widen a
retry past the window that just bound it, the loop stops instead of paying for a
query that cannot deliver.
Completeness is deliberately untouched: only the WIDENING is rationed. Every
starved project still pays its own first scoped query, which is the guarantee
the fixed per-build project cap used to break (greptile P1 on #6659). The
constants comment above PROJECT_ASSIGNED_CLI_SCAN_CEILING carried the same
overclaim ("one small project-scoped query per starved project") and now states
the widening budget.
Verified: 88 tests pass across
tests/test_project_assigned_cli_session_limit.py (75),
tests/test_issue2628_cli_sessions_perf.py and
tests/test_issue4842_cron_projection_perf.py. The new regression test
`test_compression_heavy_widening_is_one_pass_budget_not_per_project` is
parametrized over 1 and 3 compression-heavy starved projects and fails on the
old one-liner by showing three full-width retries (16, 16, 16) where the pool
funds one (16).
rodrigogs
634f66774b