Repository navigation
ci: Never cancel benchmark runs on master - #4211
Conversation
Benchmark workflows share one concurrency group for master pushes. With GitHub's default single pending slot, a third quick push cancels the pending one and marks master red. Push runs now use queue: max; PR runs keep cancel-in-progress. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FbcU32urUKzbRdg672xQUG
|
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Staff engineer (Cursor agent): LGTM at 494d9c2, assuming the temporary probe workflow comes out before merge. This is the follow-up I left on #4205, and it's the smallest fix: the three benchmark workflows keep their shared push group (so gh-pages writes stay serialized and in order) and just stop dropping the middle pending run. The per-event Before merge:
|
cf10c31 to
b641ccf
Compare
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Done: the probe workflows and all Generated by Claude Code |
There was a problem hiding this comment.
Benchmark Spread
Details
| Benchmark suite | Current: b641ccf | Previous: b4b502d | Ratio |
|---|---|---|---|
setOneEntity in 10k entity store |
154 ops/sec (±0.97%) |
155 ops/sec (±0.95%) |
1.01 |
This comment was automatically generated by workflow using github-action-benchmark.
There was a problem hiding this comment.
Benchmark React
Details
| Benchmark suite | Current: b641ccf | Previous: 10e15cc | Ratio |
|---|---|---|---|
data-client: getlist-100 |
238.1 ops/s (± 3.5%) |
173.93 ops/s (± 5.0%) |
0.73 |
data-client: getlist-500 |
74.63 ops/s (± 3.5%) |
53.76 ops/s (± 4.8%) |
0.72 |
data-client: update-entity |
741.76 ops/s (± 8.8%) |
434.78 ops/s (± 10.5%) |
0.59 |
data-client: update-user |
666.67 ops/s (± 10.8%) |
425.72 ops/s (± 10.2%) |
0.64 |
data-client: getlist-500-sorted |
74.63 ops/s (± 9.6%) |
55.26 ops/s (± 8.5%) |
0.74 |
data-client: update-entity-sorted |
666.67 ops/s (± 6.9%) |
400 ops/s (± 7.0%) |
0.60 |
data-client: update-entity-multi-view |
666.67 ops/s (± 9.9%) |
408.33 ops/s (± 7.5%) |
0.61 |
data-client: list-detail-switch-10 |
24.57 ops/s (± 7.5%) |
12.71 ops/s (± 7.5%) |
0.52 |
data-client: update-user-10000 |
131.58 ops/s (± 13.3%) |
84.03 ops/s (± 15.3%) |
0.64 |
data-client: invalidate-and-resolve |
65.79 ops/s (± 6.4%) |
45.98 ops/s (± 4.7%) |
0.70 |
data-client: unshift-item |
408.33 ops/s (± 4.7%) |
263.16 ops/s (± 4.6%) |
0.64 |
data-client: delete-item |
555.56 ops/s (± 5.6%) |
333.33 ops/s (± 6.0%) |
0.60 |
data-client: move-item |
322.58 ops/s (± 11.2%) |
204.17 ops/s (± 9.8%) |
0.63 |
This comment was automatically generated by workflow using github-action-benchmark.
There was a problem hiding this comment.
Benchmark
Details
| Benchmark suite | Current: b641ccf | Previous: 10e15cc | Ratio |
|---|---|---|---|
normalizeLong |
430 ops/sec (±4.32%) |
424 ops/sec (±4.38%) |
0.99 |
normalizeLong Values |
384 ops/sec (±1.16%) |
385 ops/sec (±0.30%) |
1.00 |
normalizeLong Scalar |
343 ops/sec (±3.74%) |
369 ops/sec (±3.63%) |
1.08 |
normalizeLong Scalar update |
892 ops/sec (±0.22%) |
918 ops/sec (±0.21%) |
1.03 |
denormalizeLong |
224 ops/sec (±5.73%) |
245 ops/sec (±5.79%) |
1.09 |
denormalizeLong Values |
221 ops/sec (±4.91%) |
229 ops/sec (±4.35%) |
1.04 |
denormalizeLong donotcache |
1063 ops/sec (±0.67%) |
992 ops/sec (±1.01%) |
0.93 |
denormalizeLong Values donotcache |
755 ops/sec (±0.22%) |
752 ops/sec (±0.22%) |
1.00 |
denormalizeLong Scalar donotcache |
1162 ops/sec (±0.33%) |
1029 ops/sec (±0.24%) |
0.89 |
denormalizeShort donotcache 500x |
1380 ops/sec (±0.10%) |
1402 ops/sec (±0.10%) |
1.02 |
denormalizeShort 500x |
598 ops/sec (±6.52%) |
639 ops/sec (±6.73%) |
1.07 |
denormalizeShort 500x withCache |
7206 ops/sec (±0.09%) |
6531 ops/sec (±0.21%) |
0.91 |
queryShort 500x withCache |
3395 ops/sec (±0.06%) |
3178 ops/sec (±2.76%) |
0.94 |
buildQueryKey All |
53525 ops/sec (±0.82%) |
59344 ops/sec (±1.21%) |
1.11 |
query All withCache |
6392 ops/sec (±2.87%) |
6251 ops/sec (±2.07%) |
0.98 |
denormalizeLong with mixin Entity |
219 ops/sec (±6.28%) |
217 ops/sec (±7.98%) |
0.99 |
denormalizeLong withCache |
7689 ops/sec (±0.25%) |
8085 ops/sec (±0.26%) |
1.05 |
denormalizeLong withCache (Scalar churn) |
7546 ops/sec (±0.85%) |
8027 ops/sec (±1.01%) |
1.06 |
denormalizeLong Values withCache |
6409 ops/sec (±1.48%) |
4995 ops/sec (±1.81%) |
0.78 |
denormalizeLong Scalar withCache |
7326 ops/sec (±0.73%) |
6193 ops/sec (±0.36%) |
0.85 |
denormalizeLong Scalar update withCache |
5527 ops/sec (±0.54%) |
3649 ops/sec (±0.23%) |
0.66 |
denormalizeLong All withCache |
6386 ops/sec (±0.24%) |
6359 ops/sec (±0.29%) |
1.00 |
denormalizeLong Query-sorted withCache |
6580 ops/sec (±2.40%) |
6428 ops/sec (±2.11%) |
0.98 |
denormalizeLongAndShort withEntityCacheOnly |
1626 ops/sec (±1.38%) |
1742 ops/sec (±0.27%) |
1.07 |
denormalize bidirectional 50 |
4274 ops/sec (±10.08%) |
4510 ops/sec (±12.09%) |
1.06 |
denormalize bidirectional 50 donotcache |
44762 ops/sec (±0.23%) |
41392 ops/sec (±0.61%) |
0.92 |
getResponse |
5143 ops/sec (±4.38%) |
4474 ops/sec (±3.73%) |
0.87 |
getResponse (null) |
8750694 ops/sec (±25.32%) |
10187553 ops/sec (±0.57%) |
1.16 |
getResponse (clear cache) |
205 ops/sec (±7.62%) |
205 ops/sec (±8.56%) |
1 |
getSmallResponse |
3942 ops/sec (±0.92%) |
3555 ops/sec (±0.56%) |
0.90 |
getSmallInferredResponse |
3118 ops/sec (±0.24%) |
2825 ops/sec (±0.10%) |
0.91 |
getResponse Collection |
3823 ops/sec (±4.34%) |
4545 ops/sec (±2.96%) |
1.19 |
get Collection |
2449 ops/sec (±0.22%) |
3019 ops/sec (±0.19%) |
1.23 |
get Query-sorted |
4636 ops/sec (±1.37%) |
5066 ops/sec (±1.38%) |
1.09 |
setLong |
443 ops/sec (±0.33%) |
427 ops/sec (±0.31%) |
0.96 |
setLongWithMerge |
252 ops/sec (±0.50%) |
253 ops/sec (±0.22%) |
1.00 |
setLongWithSimpleMerge |
269 ops/sec (±0.24%) |
264 ops/sec (±0.88%) |
0.98 |
setSmallResponse 500x |
892 ops/sec (±1.48%) |
934 ops/sec (±1.54%) |
1.05 |
setMany 50x one-per-row |
138 ops/sec (±0.66%) |
144 ops/sec (±0.51%) |
1.04 |
setMany 50 batch |
3613 ops/sec (±0.62%) |
3609 ops/sec (±0.48%) |
1.00 |
setMany 500x one-per-row |
14.2 ops/sec (±0.83%) |
14.49 ops/sec (±0.59%) |
1.02 |
setMany 500 batch |
1464 ops/sec (±3.53%) |
1426 ops/sec (±0.21%) |
0.97 |
This comment was automatically generated by workflow using github-action-benchmark.
Requested by Nathaniel · project thread
Before: the benchmark workflows (
benchmark.yml,benchmark-react.yml,benchmark-spread.yml) share one concurrency group for master pushes with GitHub's default single pending slot. Three quick master pushes touching their paths cancel the middle run, which marks that master commit red.After: master push runs queue (
queue: max, up to 100 pending), so every push's benchmark runs and publishes in order. PR runs still cancel superseded ones.How:
queueaccepts an expression, so each workflow picks the mode per event, alongside the existingcancel-in-progressexpression (GitHub rejectsqueue: maxonly together withcancel-in-progress: true):Verified on real runs with a temporary probe workflow using the same block (since dropped from the branch): nine rapid branch pushes left one run in progress and the rest pending in order, none cancelled; on the PR, each new push cancelled both the pending and the in-progress run, the same as a control workflow with no
queuekey. The benchmark workflows themselves also accepted the block on this PR's runs. Updates the CI rule in.cursor/rules/ci-config.mdc.🤖 Generated with Claude Code
https://claude.ai/code/session_01FbcU32urUKzbRdg672xQUG
Note
Low Risk
CI concurrency-only change for benchmark workflows; no application or release logic touched.
Overview
Benchmark GitHub Actions workflows now queue master push runs instead of letting the shared concurrency group cancel middle commits (which turned those checks red on npm scoring).
benchmark.yml,benchmark-react.yml, andbenchmark-spread.ymladd event-aware concurrency:queue: maxon push (up to 100 pending, run in order) andqueue: singleon pull requests, paired with the existingcancel-in-progressonly for PRs. Inline comments document why master runs must not be cancelled.CI agent rules in
.cursor/rules/ci-config.mdc(and the generated.claude/rules/ci-config.md) replace the note that benchmark push groups used the default single slot with this per-eventqueue/cancel-in-progresspattern forbenchmark*.yml.Reviewed by Cursor Bugbot for commit b641ccf. Bugbot is set up for automated code reviews on this repo. Configure here.