A canary published right after another can read a stale canary tag #3791
Copy link
Copy link
Closed
Labels
comp: build/pipelineBuild, bundling, packaging, release pipeline.Build, bundling, packaging, release pipeline.type: bugDefect: expected behavior doesn't happen.Defect: expected behavior doesn't happen.version: current (v17+)Targets the current modular API (v17+).Targets the current modular API (v17+).
Milestone
Description
#3784 made the publish job skip a canary whose commit is not after the commit of the canary already on npm. npm makes a new version, and the dist-tag the publish moved, visible only when its publish-time malware scan finishes, so that check can read a canary that is about to change.
Details
- Over the eight canaries published since 2026-09-27, npm listed each version 56 to 249 seconds after the Publish step finished (median 127). GitHub's changelog calls the delay "typically around five minutes".
- If two merges land close together and the older commit's publish starts inside that window, it reads the previous canary, passes the check, publishes, and leaves
canaryon the older build until the next merge.
Scope
- Only the
canarydist-tag is affected, so onlynpm install @angular/fire@canaryandng add @angular/fire@canary.latestandnextmove only on tagged releases. - It needs two merges to
mainwithin a few minutes of each other, with the older one's publish running second. - It lasts until the next merge publishes a newer canary.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
comp: build/pipelineBuild, bundling, packaging, release pipeline.Build, bundling, packaging, release pipeline.type: bugDefect: expected behavior doesn't happen.Defect: expected behavior doesn't happen.version: current (v17+)Targets the current modular API (v17+).Targets the current modular API (v17+).
Activity