Catalog deploy is skipped when two module tags are released from the same commit

What happens

Two module tags pushed on the same commit each run module-release.yml. Both runs report success, but only the first catalog deploy goes live. The second module is released on GitHub yet missing from index.json, and modules/<namespace>.json returns 404, so ws product install <namespace> cannot find it.

Seen on

A fork, releasing api/v0.1.0 then identity/v0.1.0 three minutes apart, both on commit e34f365.

• identity run: "assembled 2 module tag(s)", "wrote index.json and 2 namespace file(s)", Deploy to Pages "Reported success!"
• Served index.json kept last-modified of the api deploy and listed only api, well past the 10 minute cache.

Likely cause

actions/deploy-pages creates the deployment with pages_build_version set to the commit SHA ("Created deployment for e34f365…, ID: e34f365…"). Both runs share the SHA, so the second deployment resolves to the first one, which already succeeded, and its artifact is never served.

Workaround

Push a new commit and dispatch pages.yml on that ref. The catalog is regenerated from every tag, so one run publishes all of them.

Options

• Tag modules from different commits (process only, easy to forget)
• Have the deploy job detect that the served index.json lacks the tag it just released, and fail instead of reporting success
• Move the catalog deploy out of module-release.yml into one workflow triggered after releases, so a deploy never shares a SHA with another in flight

Start with module-release.yml and pages.yml, then inspect how deploy-pages receives the commit SHA when two tags trigger runs. Reproduce the same-commit release scenario and verify the selected workflow change prevents a stale catalog from being reported as successfully deployed.