refactor(flowcontrol): UsageLimitPolicy fills a framework-owned ceilings buffer - #2171
Open
LukeAVanDrie wants to merge 1 commit into
Open
refactor(flowcontrol): UsageLimitPolicy fills a framework-owned ceilings buffer#2171LukeAVanDrie wants to merge 1 commit into
LukeAVanDrie wants to merge 1 commit into
Conversation
…ings buffer ComputeLimit returned a slice parallel to the priorities argument, and the dispatch loop indexed it unchecked: a policy returning a short slice panicked the processor. The policy now writes into a caller-provided buffer that the framework sizes to len(priorities) and pre-fills with 1.0, so a mis-sized result is unrepresentable and an unwritten entry fails open instead of carrying stale state. The processor reuses one buffer across cycles, removing the per-cycle allocation on the 1ms dispatch path. A batch call (rather than per-band) is retained deliberately: duty-cycle policies such as soft-reflective-ceiling advance shared state once per dispatch cycle and require all gated bands to observe the same open or closed decision within a cycle. Signed-off-by: Luke Van Drie <lukevandrie@google.com>
github-actions
Bot
added
size/L
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
1 participant
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.
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
UsageLimitPolicy.ComputeLimitreturned a slice parallel to the priorities argument, and the dispatch loop indexed it unchecked: a policy returning a short slice panicked the processor. The policy now writes into a buffer the framework sizes tolen(priorities)and pre-fills with 1.0, so a short result cannot exist and a skipped entry fails open instead of keeping a stale value. The processor reuses one buffer across cycles, removing a per-cycle allocation on the 1ms dispatch path.The call stays batch-shaped rather than per-band, and the interface doc now states why: the framework calls ComputeLimit exactly once per dispatch cycle, duty-cycle policies (soft-reflective-ceiling) use that call as their tick, and computing all ceilings together is what lets every gated band see the same open/closed decision within a cycle.
Breaking SDK change for out-of-tree
UsageLimitPolicyimplementations; part of the panic-posture cleanup in #2098.Which issue(s) this PR fixes:
Part of #2098
Release note: