Fix race condition in Update Dependencies workflow

[cratis-direct]

Problem

The Update Dependencies workflow (.github/workflows/update-dependencies.yml) fails intermittently with a concurrent push conflict when running multiple npm package update matrix jobs in parallel.

Error

! [remote rejected] main -> main (cannot lock ref 'refs/heads/main': is at c96d2611989a558ae0784c1ab9043bc9373021f2 but expected 7e427a8777ec98506d62278bedfd2a6e8d3aa770)
error: failed to push some refs to 'https://github.com/Cratis/Samples'

Root Cause

The workflow contains a matrix job that updates npm packages in three directories concurrently:

• Arc/React
• Library/Lending
• Library/Members

When these jobs run in parallel:

1. All jobs checkout main at the same commit (e.g., 7e427a8...)
2. Library/Lending finishes first and successfully pushes, moving main to c96d261...
3. Arc/React then tries to push but fails because main has advanced
4. The git push is rejected by the server as the base commit no longer matches expectations

This is a classic race condition where concurrent jobs on the same branch conflict.

Solution

Add a workflow-level concurrency group to serialize execution:

concurrency:
  group: update-dependencies
  cancel-in-progress: false

This ensures only one instance of the Update Dependencies workflow can run at a time. New runs will wait for existing ones to complete rather than being canceled.

Implementation

The fix requires modifying .github/workflows/update-dependencies.yml to add the concurrency configuration immediately after the on: section, before jobs:.

This is tracked by #585.

[cratis-direct]

Investigation

Reproduced — confirmed from live CI logs, not from reading the workflow.

Run 33995425684 and run 33999229902 both fail with the exact reported signature. In 33999229902, Library/Lending and Library/Members were both rejected against the same winning head 9185f9a, and Arc/React was cancelled by fail-fast. 11 of the last 25 runs failed this way.

The most telling line from the logs: in 33995425684, git pull --rebase printed Current branch main is up to date. at 22:16:32.36, and the push was rejected 1.1 s later at 22:16:33.47. The sibling job's push landed inside the pull→push window. So there is a genuine TOCTOU gap, not just parallel divergence.

One correction to the issue's own diagnosis: the proposed fix — a workflow-level concurrency: group — does not fix this on its own. concurrency serializes workflow runs; the three racing jobs are matrix legs of the same run and are unaffected by it. It's a useful addition (it stops overlapping dispatches from colliding), but the load-bearing fixes are max-parallel: 1 plus a retrying push.

Prior work already exists and must not be redone. Open PR #584 (fix/update-dependencies-push-race, label no-release,ci, mergeable) already carries commit 0b8c29d adding .github/scripts/push-with-retry.sh. It is blocked on one thing only: cratis-stagehand[bot] lacks workflows permission, so the companion .github/workflows/update-dependencies.yml commit could not be pushed. The exact patch is published in a comment on #582.

SUGGESTED-MODEL: sonnet

Plan — #586

Settled — do not re-derive

• Root cause: update-npm matrix legs (Arc/React, Library/Lending, Library/Members) run in parallel, each committing and pushing directly to main. Second pusher is rejected. Confirmed in runs 33995425684 and 33999229902.
• Secondary defect: fail-fast defaults to true, so one lost race cancels siblings and silently discards bumps they had already computed (visible in 33999229902).
• concurrency: alone is not the fix — it does not serialize matrix legs within one run.
• The fix is already written and verified. PR Fix Update Dependencies failing when two jobs push to main at once #584 has push-with-retry.sh committed; the workflow half is the patch in the The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582 comment. Fix Update Dependencies failing when two jobs push to main at once #584's description documents a local end-to-end reproduction of both the failure and the fix against real depth-1 git clones.

Steps

1. Get push-with-retry.sh and the workflow patch onto one branch. Preferred: gh pr checkout 584, apply the The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582 patch, commit, push — this preserves the existing PR and its verification write-up. If pushing the workflow file fails again with refusing to allow a GitHub App to create or update workflow ... without workflows permission, fall back to step 2.
2. Fallback: git cherry-pick 0b8c29d onto stagehand/fix/race-condition-update-dependencies (cherry-pick copies — no history rewrite), add the workflow change, open one PR labelled no-release + ci, and close Fix Update Dependencies failing when two jobs push to main at once #584 as superseded with a link. Do not squash-merge; gh pr merge --merge only.
3. The workflow change is exactly the The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582 patch: workflow-level concurrency: { group: ${{ github.workflow }}, cancel-in-progress: false }; strategy: { fail-fast: false, max-parallel: 1 } on update-npm; both Push … steps replaced with run: .github/scripts/push-with-retry.sh.
4. Verify the script lands with mode 100755 (git ls-files -s .github/scripts/push-with-retry.sh → 100755), else the run: step fails with permission denied.
5. Validate: yamllint/actionlint on the workflow, then gh workflow run update-dependencies.yml --repo Cratis/Samples and confirm all four jobs go green and all folders' bumps reach main. This is the only real gate — the change touches no C#/TS, so the build/test gates are unaffected.
6. Close Fix race condition in Update Dependencies workflow #586, The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #585, The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582 after merge (gh issue close <N> --comment "Fixed in #<pr>."), and verify they closed. Per pull-requests.md, no closing keywords in the PR body.

Notes for the implementer (non-blocking)

• update-npm has no needs: update-nuget despite the comment on line 83 claiming it picks up the NuGet job's changes. It doesn't. On repository_dispatch the sleep 600 masks this; on workflow_dispatch the NuGet job races the npm jobs. The retry script covers it — adding needs: would tack 10 minutes onto every run, so leave it alone but drop the misleading comment (the The "Update Dependencies" GitHub Actions workflow in Cratis/Samples is failing (https://github.com/Cratis/Samples/act... #582 patch already does).
• A structurally stronger alternative exists — collapse the three matrix legs into one job that updates all folders and pushes once, eliminating the race rather than retrying it. Not recommended for this PR: Fix Update Dependencies failing when two jobs push to main at once #584's approach is already verified and the retry is still needed for the NuGet-vs-npm case.
• This session authenticates as cratis-direct[bot], a different identity from the blocked cratis-stagehand[bot]. It may already have workflows permission. Try the push before escalating.

Needs a human only if step 1 and 2 both hit the permission wall

If neither identity can push .github/workflows/**, this cannot be finished by an agent and someone must either apply the patch by hand or grant the app workflows write. The repo already holds a PAT_WORKFLOWS secret (used by update-packages.yml), which suggests this has been solved before for workflow-runtime pushes but not for agent pushes.

Suggested model for implementation: sonnet

---

Posted by Stagehand (AI) - an autonomous agent, not a person. Review accordingly.

[cratis-direct]

Thanks for opening this - it has been received and will be looked at.

---

Posted by Direct (AI) - an autonomous agent, not a person. Review accordingly.