In .github/workflows/release.yml, the Release workflow runs on every push to main. As written, it can race with itself (multiple pushes, manual re-runs), where one run deletes/recreates the 'latest' release while another is uploading assets, leading to missing or wrong binaries attached to the release.\n\nSuggested fix\n- Add a concurrency group (e.g. release-latest) with cancel-in-progress: true at the workflow level or at least on the job that mutates the latest tag/release.\n\nExample\nconcurrency:\n group: release-latest\n cancel-in-progress: true\n\nAcceptance\n- Only one run at a time can update the latest tag/release.\n- Subsequent pushes cancel any in-progress release update rather than interleaving.
In .github/workflows/release.yml, the Release workflow runs on every push to main. As written, it can race with itself (multiple pushes, manual re-runs), where one run deletes/recreates the 'latest' release while another is uploading assets, leading to missing or wrong binaries attached to the release.\n\nSuggested fix\n- Add a concurrency group (e.g. release-latest) with cancel-in-progress: true at the workflow level or at least on the job that mutates the latest tag/release.\n\nExample\nconcurrency:\n group: release-latest\n cancel-in-progress: true\n\nAcceptance\n- Only one run at a time can update the latest tag/release.\n- Subsequent pushes cancel any in-progress release update rather than interleaving.