This is an automated email from the ASF dual-hosted git repository. github-merge-queue[bot] pushed a commit to branch gh-readonly-queue/main/pr-8523-f642c183dc5461f31b84f6bd37dc12e917ca3fdd in repository https://gitbox.apache.org/repos/asf/texera.git
commit 279e12b2cd469c5cadaf69d987513f9b2552e2e6 Author: Meng Wang <[email protected]> AuthorDate: Mon Sep 21 05:49:34 2026 +0000 fix(ci): stop cancelling in-progress Backport Approvals runs (#8523) ### What changes were proposed in this PR? `Backport Approvals` is a required status check on `main`, and GitHub evaluates the LATEST check run with that name. The workflow's concurrency group had `cancel-in-progress: true`, so when two PR events land close together (a push right after a review request or a label change), the newer run cancels the older one — and when the older run's "cancelled" terminal state is recorded after the newer run's success, the required check reads as failed and the merge button is blocked. This happened on #8516: the check showed a cancelled run as its latest state while a sibling run of the same commit had already passed; re-running the cancelled run unblocked the merge. The job completes in seconds, so cancellation saves nothing. This stops cancelling the in-progress run (`cancel-in-progress: false`). GitHub still keeps at most one pending run per concurrency group and replaces it on a newer event, but a replaced pending run is cancelled before its successor even starts, so its cancelled state can never land last: the latest check run on the commit always ends as a real verdict. A skipped intermediate evaluation loses nothing, because the job reads the live labels and reviews at run time rather than the event payload. ### Any related issues, documentation, discussions? Closes #8522. Observed on #8516 (a cancelled `Backport Approvals` run blocked an otherwise green merge). ### How was this PR tested? Config-only change to the workflow's concurrency setting; no executable code path changes. Verified the failure mechanism on #8516: the blocked merge showed the cancelled run as the latest `Backport Approvals` check run, and re-running it (6s pass) unblocked the merge immediately. ### Was this PR authored or co-authored using generative AI tooling? Yes. Generated-by: Claude Code (Claude Fable 5, Anthropic). Reviewed by the author before submission. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <[email protected]> --- .github/workflows/backport-approval-check.yml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/.github/workflows/backport-approval-check.yml b/.github/workflows/backport-approval-check.yml index f37a52505c..6f92f08935 100644 --- a/.github/workflows/backport-approval-check.yml +++ b/.github/workflows/backport-approval-check.yml @@ -58,7 +58,15 @@ permissions: concurrency: group: backport-approvals-${{ github.event.pull_request.number || github.ref }} - cancel-in-progress: true + # Never cancel the run in progress: this is a required status check, and GitHub + # takes the LATEST check run with this name -- a cancelled in-progress run's + # terminal state can land after a newer run's success (the job is seconds long) + # and block the merge as a failed required check. GitHub still keeps at most one + # pending run per group and replaces it on a newer event, but a replaced pending + # run is cancelled before its successor even starts, so the last word on the + # commit is always a real verdict. A skipped intermediate event loses nothing: + # the job reads the live labels and reviews at run time, not the event payload. + cancel-in-progress: false jobs: backport-approvals:
