Trim sweep-enabled concurrency to min instead of max#1576
Conversation
For PRs labeled `sweep-enabled`, `--trim-conc` now collapses each parallelism config to its lowest concurrency point instead of its highest. Validation runs that only need a smoke point are cheaper at the bottom of the curve and free up shared-cluster time for full-sweep work elsewhere. Updated the conflicting-labels error in `run-sweep.yml` and the matching paragraphs in `AGENTS.md` so the operator-facing wording matches the new behavior.
There was a problem hiding this comment.
LGTM — mechanical max→min flip in trim_conc() with matching doc/error-message updates.
Extended reasoning...
Overview
This PR flips the trim_conc() behavior in utils/process_changelog.py from keeping the highest concurrency point per parallelism config to keeping the lowest. The change is three lines of code (max → min in two places, max(conc) → min(conc) in the multi-node branch) plus corresponding documentation updates in AGENTS.md and the conflicting-labels error message in .github/workflows/run-sweep.yml.
Security risks
None. This is benchmark sweep configuration logic — no auth, crypto, user input, or external surface area. Worst case impact is selecting different concurrency points for labeled PR benchmark runs.
Level of scrutiny
Low. Behavior only changes on the sweep-enabled PR label path (--trim-conc); full-sweep-enabled and push-to-main paths are untouched, so main-branch performance tracking is unaffected. The change is mechanical and the three files are kept consistent (code, docs, error message all reference 'min' / 'lowest' now).
Other factors
The bug hunting system found no issues. The diff is small (~10 lines effective change) and self-contained. No tests were updated, but the existing function is straightforward and the inversion is symmetric (min and max behave identically structurally over a non-empty iterable of comparable ints).
Resolves conflicts with PR #1576 (trim-to-min). For the multi-conflicting-labels guardrail in run-sweep.yml and the matching prose in AGENTS.md, keep this branch's three-label structure (sweep-enabled / full-sweep-enabled / non-canary-full-sweep-enabled) and the canary-gate description for full-sweep-enabled, and update the sweep-enabled wording from "max(conc)" → "min(conc)" to match the new trim_conc behavior on main. utils/process_changelog.py auto-merged cleanly to the new lowest-`conc` implementation.
Summary
trim_conc()inutils/process_changelog.pynow keeps the lowest concurrency point per parallelism config (was: highest). Single-node entries collapse to the min-concentry per group; multi-nodeconc-lists collapse to[min(conc)]..github/workflows/run-sweep.ymland the trim-behavior paragraphs inAGENTS.mdto match.Behavior only changes for PRs with the
sweep-enabledlabel (the--trim-concpath).full-sweep-enabledand push-to-main runs are unaffected — they continue to run the full untrimmed sweep.Test plan
sweep-enabledto confirm the trimmed configs land on min(conc) per parallelism row.Note
Medium Risk
Changes which benchmark points run on labeled PR sweeps (lower load, different latency/throughput signal); full sweeps and main pushes are unaffected.
Overview
For PRs labeled
sweep-enabled, the--trim-concpath now keeps the lowest concurrency per parallelism config instead of the highest.trim_conc()inutils/process_changelog.pyusesminfor single-node grouping and collapses multi-nodeconclists to[min(conc)]. Docs inAGENTS.mdand the conflicting-labels message inrun-sweep.ymlwere updated to match.full-sweep-enabledand push-to-main sweeps are unchanged.Reviewed by Cursor Bugbot for commit 6342f9e. Bugbot is set up for automated code reviews on this repo. Configure here.