Every push to main and every weekday scheduled run builds a canary and runs npm publish --tag canary, which moves the canary dist-tag to that build. Nothing checks that the build is newer than the one the tag already points at, so the tag can end up on an older build.
Details
- Two merges close together can publish out of order. Each merge starts its own workflow run, and the publish job waits for that run's tests. If a second merge lands while the first run is still going and the first run's tests finish last, the older commit's canary publishes last and takes the tag.
- A run takes about 6 to 7 minutes. On 2026-09-27 the run for
f182972 started 21 seconds after the canary for 84a8a51 had published.
- Re-running an older run can publish it late. A run on
main whose canary never published, for example because a test failed, publishes when it is re-run, even if newer canaries have gone out since.
- Nothing puts the tag back. The weekday scheduled run rebuilds the latest commit on
main, whose version is already on npm, so its publish fails with E403 (example). The tag stays on the older build until the next merge.
Scope
I have not seen the tag move back yet. While it sits on an older build, npm install @angular/fire@canary installs that build.
Every push to
mainand every weekday scheduled run builds a canary and runsnpm publish --tag canary, which moves thecanarydist-tag to that build. Nothing checks that the build is newer than the one the tag already points at, so the tag can end up on an older build.Details
f182972started 21 seconds after the canary for84a8a51had published.mainwhose canary never published, for example because a test failed, publishes when it is re-run, even if newer canaries have gone out since.main, whose version is already on npm, so its publish fails withE403(example). The tag stays on the older build until the next merge.Scope
I have not seen the tag move back yet. While it sits on an older build,
npm install @angular/fire@canaryinstalls that build.