fix(ci): source review catalog account-cap default from policy, not a literal - #1487
Merged
Merged
Conversation
… literal contextual_orchestrator_review_launcher.py's two build_zdr_prioritized_catalog call sites hand-typed "4" as the ORCHESTRATOR_CATALOG_ACCOUNT_CAP fallback instead of referencing contextual_orchestrator_review_policy.DEFAULT_ACCOUNT_CAP, the module that actually declares the intended default. The two values happen to agree on main today, but nothing enforced that. That silent-drift class is not hypothetical: a separate in-flight branch's own equivalent helper (_catalog_family_cap()) fell back to REVIEW_PREFLIGHT_MAX_TOTAL_ROUTES -- the *total* preflight budget -- instead of the per-account cap, which in a live production run let two rate-limited NVIDIA NIM credentials sharing one upstream jointly consume all 12 preflight slots (probed_count: 12, ready_count: 2, rejected_count: 10, 83% rejected via 429/404/timeout). That is the real, verified "빈 깡통 경로" (empty-can route) budget waste this change guards main against. Adds a small _catalog_account_cap(default) helper used at both call sites, plus regression tests pinning the default to policy.DEFAULT_ACCOUNT_CAP and forbidding the total-routes constant (or the old "4" literal) from reappearing as the account-cap fallback. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPmJErfkcHer4UVEgrQxUX
|
Warning Review limit reachedNext included review available in 48 minutes. View limit detailsLimit details: You’ve used the included review currently available. You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
seonghobae
pushed a commit
that referenced
this pull request
Aug 31, 2026
… cap no-op bug Rebases this branch onto main's provider_account/account_cap rename (#1468) and Noema-independence work (#1477/#1480), then fixes a real bug this branch's own batched-preflight merge introduced: _catalog_family_cap() defaulted to REVIEW_PREFLIGHT_MAX_TOTAL_ROUTES (24) whenever ORCHESTRATOR_CATALOG_FAMILY_CAP was unset, silently disabling per-account diversification. Live production evidence: probed_count 12, ready_count 2, rejected_count 10 (83% rejected via 429/404/timeout), with the admitted free-pool catalog 100% nvidia_nim/nvidia_nim_sub -- two credentials sharing one rate-limited upstream jointly occupying the entire 12-slot preflight batch. Reported at #1415 (comment) Fix (mirrors the pattern in open main PR #1487's diff, not yet merged): renamed the helper to _catalog_account_cap(default), which now requires the caller to supply contextual_orchestrator_review_policy.DEFAULT_ACCOUNT_CAP (4) as the default instead of hand-typing/defaulting to a total-routes-scale constant. An explicit ORCHESTRATOR_CATALOG_ACCOUNT_CAP override remains honored. The sidecar shell script's equivalent CATALOG_FAMILY_CAP default (also baked to the total 24-route budget) is renamed to CATALOG_ACCOUNT_CAP and restored to a real, smaller cap (8, main's existing operational value). Also corrects CHANGELOG.md and docs/adr/0003 prose that had described the no-op 24-route cap as an intentional fix, and updates two contract tests (test_contextual_orchestrator_review_runtime_preflight.py, test_contextual_orchestrator_review_sidecar_contract.py) that pinned the old family_cap naming and the buggy default. Verification: coverage run -m pytest tests -> 2122 passed, 1 skipped, 21 subtests; coverage report -> 100% on scripts/ci; interrogate -> 100% docstrings; bash -n on the touched shell script; git diff --check clean. Red-then-green: reverting _catalog_account_cap's default back to REVIEW_PREFLIGHT_MAX_TOTAL_ROUTES makes the new regression tests fail; restoring the fix makes them pass again. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KPmJErfkcHer4UVEgrQxUX
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Investigated a reported "빈 깡통 경로 너무 많다" (too many empty-can routes) bug: the
review sidecar's bounded preflight budget was allegedly being wasted because
the per-account/family diversity cap silently fell back to the total routes
budget instead of a real per-account cap, letting two rate-limited NVIDIA NIM
credentials sharing one upstream jointly occupy the whole 12-slot preflight
budget (a live run showed
probed_count: 12, ready_count: 2, rejected_count: 10— 83% rejected via 429/404/timeout).What I found investigating on current
main(this PR's actual scope):(
_catalog_family_cap()defaulting toREVIEW_PREFLIGHT_MAX_TOTAL_ROUTES,and PR fix(ci): keep sidecar credential accounts independent #1468 not being landed) do not exist on
main—#1468isalready merged, and
main'sbuild_zdr_prioritized_catalogcall sitesalready default
ORCHESTRATOR_CATALOG_ACCOUNT_CAPto"4", matchingcontextual_orchestrator_review_policy.DEFAULT_ACCOUNT_CAP.git log --all -S _catalog_family_capshows that function only everexisted on a different, unmerged branch
(
fix/noema-batched-preflight-413-evidence, PR fix(noema): batch sidecar route preflight #1415) — a real bug, butnot one on
main, and not one I can push a fix for (that branch belongs toanother in-flight agent; I left a review comment on fix(noema): batch sidecar route preflight #1415 instead flagging
the exact lines and evidence).
("outage domain") rather than by credential account, since
nvidia_nim/nvidia_nim_subshareintegrate.api.nvidia.com— is alreadyin progress as open PR fix(ci): group review catalog admission/diversity by outage domain, not account #1474. I did not duplicate it.
report (bound concurrency / stagger preflight requests sharing an account)
does not apply:
_preflight_review_agentsin this repo's launcher alreadyprobes routes strictly sequentially, one
proxy_send_oncecall at a time,zero retries — there is no concurrent burst to bound.
is_freegap (contextual-orchestrator PR [Fleet incident] Resolve independent-review bootstrap deadlock for sole-collaborator repositories #948) is confirmedstill open/unmerged, but is explicitly a separate, already-tracked,
already-PR'd issue — out of scope here, untouched.
What this PR actually fixes: a real, currently-existing gap on
mainthat let the above happen in the first place and can let it happen again:
main's twobuild_zdr_prioritized_catalogcall sites hand-typed"4"asthe
ORCHESTRATOR_CATALOG_ACCOUNT_CAPfallback instead of referencingcontextual_orchestrator_review_policy.DEFAULT_ACCOUNT_CAP(the module thatactually declares the intended default). The two values happen to agree on
maintoday, but nothing enforced that — and the sibling_catalog_family_cap()bug on PR #1415 is live proof of exactly this drift class actually happening.
Changes
scripts/ci/contextual_orchestrator_review_launcher.py: new_catalog_account_cap(default)helper; bothbuild_zdr_prioritized_catalogcall sites now pass
account_cap=_catalog_account_cap(DEFAULT_ACCOUNT_CAP)(imported from the policy module) instead of a literal
"4".tests/test_contextual_orchestrator_review_runtime_preflight.py: three newregression tests —
policy.DEFAULT_ACCOUNT_CAPand is never equalto (or derived from)
REVIEW_PREFLIGHT_MAX_TOTAL_ROUTES;ORCHESTRATOR_CATALOG_ACCOUNT_CAPoverride still applies;main()call sites to_catalog_account_cap(DEFAULT_ACCOUNT_CAP)and forbiddingORCHESTRATOR_CATALOG_FAMILY_CAP/the old"4"literal from reappearing.CHANGELOG.md:Unreleasedentry.Pre-existing coverage already proves the two properties the original report
asked to regression-test:
test_routable_discovered_models_excludes_evidence_only_rows(evidence_only/OpenRouter rows never reach the budget-consuming routing path)
and the absence of any cache/blacklist structure in
contextual_orchestrator/model_discovery.py(discovery is fully statelessper run, so a recovered Bytez is trivially reconsidered next run — no state
to expire).
Test plan
coverage run -m pytest tests -q— 2108 passed, 1 skipped, 21 subtests passedcoverage report --show-missing— 100% onscripts/ci/interrogate— 100%bash -n scripts/ci/contextual_orchestrator_review_sidecar.sh(untouched, sanity-checked)git diff --check— cleanorigin/main(71633cd0) and re-ran the full gate suite after rebaseRelated
described
_catalog_family_cap()bug; flagged via review comment, nottouched directly (protected, another agent's in-flight work).
PR builds on.
refinement; not duplicated here.
is_freegap; confirmed out of scope, untouched.
🤖 Generated with Claude Code
https://claude.ai/code/session_01KPmJErfkcHer4UVEgrQxUX
Generated by Claude Code