gap-ratio: gate demand inflation to the bootstrap window#38
Open
TianyeGGBond wants to merge 1 commit into
Open
gap-ratio: gate demand inflation to the bootstrap window#38TianyeGGBond wants to merge 1 commit into
TianyeGGBond wants to merge 1 commit into
Conversation
The has_pending inflation double-counted demand for a rollout that was still open but already reporting progress, since the rollout_open_pipelines entry survives until release/clear_progress. Gate it on the no-progress (bootstrap) condition so actively-progressing rollouts are not double-counted and gap-ratio fairness holds (rlops#36). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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.
Context
Fixes #36 (S12-INFLATE-WINDOW from the F1-F12 scheduler review).
In
plan_generation_gap_ratio, the demand-inflation branch:was meant to fire only during the bootstrap window ("request sent, no
progress yet"). But its condition only checks
rollout_open_pipelinesmembership, and that entry survives until release /
clear_progress. Sowhile a rollout is actively progressing (
step_target > 0), the branchstill fires and demand is double-counted (
remaining = actual_remaining + step_target,percent_remaining > 1), skewing gap-ratio toward whicheverpipeline happens to hold an entry when the other doesn't.
Not a hang — allocation-fairness drift.
Change
scheduler/planner.py:in_bootstrap_window = step_target <= 0.0before the estimatebranch overwrites
step_target.has_pending and in_bootstrap_windowso it onlyapplies when no progress has been reported yet.
The bootstrap path is byte-for-byte unchanged; only the erroneous
firing on an actively-progressing rollout is removed.
Net: +5 / -3 lines.
🤖 Generated with Claude Code