When autoupdate merges main into an open PR's branch while that PR's CI is still running, the new merge commit trips concurrency: { group: ci-${{ github.ref }}, cancel-in-progress: true } (.github/workflows/ci.yml:9-11) and cancels the in-flight run, then starts a fresh full-matrix run from scratch.
Run 28689755075 (sha 1ed94f9e) was ~180/189 tests into several E2E levels — and had surfaced a realAccountDaoTest.observeAllAndGetAllReturnAccountsOrderedByEmail failure on E2E (30) and (31).
#245 merged → autoupdate pushed fa0c7c4 "Merge main into feat-164-reorder-accounts" → that push started run 28690100260 and cancelled28689755075 mid-flight.
Impact
Wasted CI minutes (full multi-API matrix restarts from zero).
A low-priority PR that keeps getting rebased as main advances can struggle to ever complete a run.
Diagnostic churn — near-complete failure detail is discarded when the run is cancelled.
Notes
fail-fast: false is already set on the E2E matrix (ci.yml:148), so within a run one API level failing does NOT cancel siblings. This ticket is specifically about whole-run cancellation caused by rebasing mid-run.
Options
Have autoupdate skip a PR whose latest CI run is in_progress/queued (only rebase when its CI is idle).
Only autoupdate PRs at/near the front of the merge queue (defer low-priority rebases).
Debounce: don't rebase a given PR more than once per N minutes.
Acceptance
autoupdate no longer cancels an in-progress CI run by rebasing mid-flight; behind PRs still get updated once their CI is idle / main is stable.
## Problem
When `autoupdate` merges `main` into an open PR's branch **while that PR's CI is still running**, the new merge commit trips `concurrency: { group: ci-${{ github.ref }}, cancel-in-progress: true }` (`.github/workflows/ci.yml:9-11`) and **cancels the in-flight run**, then starts a fresh full-matrix run from scratch.
## Evidence (2026-07-04, PR #240)
- Run `28689755075` (sha `1ed94f9e`) was ~180/189 tests into several E2E levels — and had surfaced a **real** `AccountDaoTest.observeAllAndGetAllReturnAccountsOrderedByEmail` failure on E2E (30) and (31).
- `#245` merged → autoupdate pushed `fa0c7c4 "Merge main into feat-164-reorder-accounts"` → that push started run `28690100260` and **cancelled** `28689755075` mid-flight.
## Impact
- Wasted CI minutes (full multi-API matrix restarts from zero).
- A low-priority PR that keeps getting rebased as `main` advances can struggle to ever *complete* a run.
- Diagnostic churn — near-complete failure detail is discarded when the run is cancelled.
## Notes
- `fail-fast: false` is already set on the E2E matrix (`ci.yml:148`), so within a run one API level failing does NOT cancel siblings. This ticket is specifically about **whole-run** cancellation caused by rebasing mid-run.
## Options
1. Have autoupdate **skip a PR whose latest CI run is in_progress/queued** (only rebase when its CI is idle).
2. Only autoupdate PRs at/near the front of the merge queue (defer low-priority rebases).
3. Debounce: don't rebase a given PR more than once per N minutes.
## Acceptance
autoupdate no longer cancels an in-progress CI run by rebasing mid-flight; behind PRs still get updated once their CI is idle / main is stable.
Closing per request — filed while diagnosing an unexpected mid-run CI cancellation, but it turned out to be expected concurrency: cancel-in-progress behavior (autoupdate rebasing a PR while its CI is running supersedes the in-flight build), not a defect. No change needed.
Closing per request — filed while diagnosing an unexpected mid-run CI cancellation, but it turned out to be expected `concurrency: cancel-in-progress` behavior (autoupdate rebasing a PR while its CI is running supersedes the in-flight build), not a defect. No change needed.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
When
autoupdatemergesmaininto an open PR's branch while that PR's CI is still running, the new merge commit tripsconcurrency: { group: ci-${{ github.ref }}, cancel-in-progress: true }(.github/workflows/ci.yml:9-11) and cancels the in-flight run, then starts a fresh full-matrix run from scratch.Evidence (2026-07-04, PR #240)
28689755075(sha1ed94f9e) was ~180/189 tests into several E2E levels — and had surfaced a realAccountDaoTest.observeAllAndGetAllReturnAccountsOrderedByEmailfailure on E2E (30) and (31).#245merged → autoupdate pushedfa0c7c4 "Merge main into feat-164-reorder-accounts"→ that push started run28690100260and cancelled28689755075mid-flight.Impact
mainadvances can struggle to ever complete a run.Notes
fail-fast: falseis already set on the E2E matrix (ci.yml:148), so within a run one API level failing does NOT cancel siblings. This ticket is specifically about whole-run cancellation caused by rebasing mid-run.Options
Acceptance
autoupdate no longer cancels an in-progress CI run by rebasing mid-flight; behind PRs still get updated once their CI is idle / main is stable.
Closing per request — filed while diagnosing an unexpected mid-run CI cancellation, but it turned out to be expected
concurrency: cancel-in-progressbehavior (autoupdate rebasing a PR while its CI is running supersedes the in-flight build), not a defect. No change needed.