ci: drop concurrency group on init_release, use race-tolerant find-or-create#5668
Conversation
…find-or-create
The previous design serialized all init_release jobs via
concurrency:
group: release-init-${{ github.sha }}
cancel-in-progress: false
That ran into GitHub's "1 running + 1 pending" rule on concurrency
groups: when a third job tries to enter the group, the currently-
pending one is cancelled in favor of the newer arrival. Triggering all
156 package workflows at once caused ~142 of them to be cancelled
before their init_release even got a chance to run.
Replace serialization with a race-tolerant find-or-create loop that
all 156 init jobs run in parallel:
- Stagger start 0-9s to reduce thundering-herd on the first query.
- Up to 6 attempts: look up drafts matching this SHA + tag_name
(strongest key); use the one with the lowest id (deterministic
winner).
- If none exist, POST create; sleep 2-5s; re-query. Multiple creates
may race during the initial burst, producing a handful of
duplicate drafts, but every worker converges on the same
lowest-id draft.
- Fail hard after 6 attempts.
Duplicates from races are not deleted here (deletion under contention
risks a worker using a just-deleted release). A follow-up can sweep
zero-asset duplicate drafts periodically if the list grows.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
Important Review skippedToo many files! This PR contains 156 files, which is 6 over the limit of 150. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (156)
You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|



Summary
Fixes a mass-cancellation bug in #5666 that only surfaces when many package workflows are dispatched at once.
Problem observed
After merging #5666 and dispatching all 156 package workflows at the same commit:
Only ~15 workflows ever ran to completion. The other 141 were cancelled before their
init_releasestep even started.Root cause
The init_release job was serialized via:
Per GitHub's docs on concurrency groups:
So the group holds at most 1 running + 1 pending. Triggering 156 workflows simultaneously caused a rolling cancellation: each new arrival displaced the previously-pending one, cancelling it. Net result: only the first-arrived and last-arrived ever progressed past init.
The Option A design from #5666 was validated with just 2 parallel workflows — at N=2, the
1 running + 1 pendingcap fits exactly, so the bug didn't show. At N=156 it's catastrophic.Fix
Drop the concurrency group entirely. All 156 init_release jobs run in parallel and converge via a race-tolerant find-or-create loop:
Key properties:
Validation
concurrencykey is absent from theinit_releasejob.Out of scope
Test plan
CI-package-*workflows on the new HEAD SHA.gh api repos/sysown/proxysql/releasesafter completion — ideally ≤ 5 duplicate empty drafts (from race), to be cleaned up manually if so.