Handle opportunistic batching correctly during PodGroup scheduling cycle#138754
Conversation
|
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: macsko The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
| // In this case, a previous pod was scheduled by another profile, meaning we can't use the state anymore. | ||
| if cycleCount != b.lastCycle.cycleCount+1 { | ||
| // In case of PodGroup scheduling cycle, multiple pods can share the same cycle count. | ||
| if cycleCount != b.lastCycle.cycleCount && cycleCount != b.lastCycle.cycleCount+1 { |
There was a problem hiding this comment.
Shouldn't the cycleCount != b.lastCycle.cycleCount check be actually hidden behind the GenericWorkload feature gate?
There was a problem hiding this comment.
Such case shouldn't happen without PodGroup scheduling cycle, but added a feature gate check for clarity, PTAL
e3bd12d to
0d9aca8
Compare
|
/lgtm |
|
LGTM label has been added. DetailsGit tree hash: 1971777d3daec811e2bd9d630ea5285904f40547 |
|
/lgtm |
Move diff parsing, three dedup passes, the confidence/severity gate, inline-eligibility snapping, and payload + fallback rendering out of skill prose and into ~/.claude/bin/code-review-helper. Cuts the skill body roughly in half (-156 / +33 net) and makes every deterministic rule unit-tested + golden-tested against three real OSS PR fixtures (vercel/next.js#93491, kubernetes/kubernetes#138754, prisma/prisma #29514). Capturing those fixtures uncovered three accuracy bugs in the dedup logic, all fixed in this commit with regression tests: - Semantic dedup duplicate-emit: in[i] = keep mutation left the surviving finding at two slice slots, so the final loop emitted it twice. Replaced the in-place rewrite with a current-by-ID map + preserved-order slice. - Cross-ref cascade: positional dedup mutated Explanation to embed the dropped peer's file path, which then tripped semantic Rule 1 on any later finding in that file. Cross-refs now live on a new Finding.CrossRefs []CrossRef field rendered at output time; the matchers always see the specialist's pristine Explanation. - Non-deterministic positional sort tiebreak when conf, domain, and specialist all matched. Added a final cluster[i].ID < cluster[j].ID comparator. Settings hook now routes .go files through gofmt and other extensions through prettier, and tools/code-review-helper/bin/ is gitignored. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
What type of PR is this?
/kind bug
What this PR does / why we need it:
This PR allows the batch result to be reused for pods from the same pod group during the pod group scheduling cycle. All pods during that cycle share the same cycle count. Before, such behavior made the batch state incompatible.
Which issue(s) this PR is related to:
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: