Create GitHub Release and Slack still key off `published == 'true'`, so they can announce a half-shipped release that is not on npm yet

Workflow: .github/workflows/release.yml @ f5aeaa869c1c15b7604e14047354059b5bd1f5c5
Scripts: scripts/check-published.mjs, scripts/generate-release-slack-payload.mjs

What happens

The Release job already knows a publish can be left half-shipped. From the comment above Verify every package version on this commit is on npm:

changeset publish runs one pnpm publish per package and one failure leaves the release half-shipped, with workflow possibly pointing at a @workflow/core that is not on npm yet. 5.0.0-beta.48 shipped 7 of 21 packages on its first attempt…

check-published.mjs is the check that job runs after publishing, whatever the publish step's outcome. It GETs the registry and fails when a publishable version is NOT ON NPM, or when the branch dist-tag does not point at it. The script's own header:

npm does not commit a publish synchronously: pnpm publish exits 0 once the version is staged, and the version list and dist-tag catch up afterwards. The lag is minutes, not seconds… 5.0.0-beta.48 left @workflow/web staged for about a day, which no retry budget can wait out.

Create GitHub Release and Post release notes to Slack do not mention that check. Both still run under:

if: steps.changesets.outputs.published == 'true'

published is Changesets reporting the publish script, not the registry. Slack is fed PUBLISHED_PACKAGES so the payload “matches the exact set of packages published.” generate-release-slack-payload.mjs never GETs npm. The post is :rocket: New release: <release url>.

continue-on-error: true is only there so a broken Slack token must not turn a successful release red (token_expired, then invalid_auth). It is not a dependency on the verify step.

GitHub Actions fail-fast means those two steps are skipped today when Verify every package version on this commit is on npm exits 1. That is job order, not an if. The authorize condition is still published == 'true'.

Why this matters

The invariant check-published.mjs exists to keep trustworthy is “every non-private package … must have its manifest version in the registry's version list, and the branch's dist-tag must point at it.” Slack and the GitHub Release still speak from Changesets' list.

So the room can be told the ship happened while the script would print NOT ON NPM, or while a version is only staged. Installers then hit the half-ship the comments already name: workflow pointing at an @workflow/core that does not exist yet.

Evidence

You already measured this on your own releases (from check-published.mjs):

• 5.0.0-beta.48 shipped 7 of 21 packages on its first attempt; @workflow/web stayed staged for about a day.
• 5.0.0-beta.49: just over 5m for @workflow/web to appear in the registry.
• 5.0.0-beta.50: 1m29s @workflow/astro, 3m03s @workflow/core (9.4MB), 4m11s @workflow/web (11.3MB).

On that window, Changesets can already have published == 'true' (pnpm publish exited 0 once staged). The Slack/Release if would be true. The verify step would still be retrying or exiting 1.

What we would like

Gate Create GitHub Release and Post release notes to Slack on the verify step succeeding — the same “whatever the publish step's outcome” rule you already wrote — not only on steps.changesets.outputs.published == 'true'.

Either:

if: steps.changesets.outputs.published == 'true' && steps.<verify>.outcome == 'success'

or make those two steps needs the registry check so the announce cannot outrun “NOT ON NPM.”

Optionally have generate-release-slack-payload.mjs refuse to post unless the versions in PUBLISHED_PACKAGES are visible and dist-tagged, so the payload cannot say “New release” for a version the registry will not serve.

Start with .github/workflows/release.yml, tracing the Verify every package version on this commit is on npm step and the conditions on Create GitHub Release and Post release notes to Slack. Review scripts/check-published.mjs and scripts/generate-release-slack-payload.mjs for the existing verification behavior. Done means both announcements run only after registry verification succeeds, while Slack token failures remain non-blocking.