ci: wait out npm's registry propagation before installing the published SDK - #42
Merged
Conversation
…ed SDK `publish-plugins` rewrites each plugin's SDK dependency from `file:` to the version `publish-sdk` has just pushed, then reinstalls. That install has to resolve the SDK from the registry seconds after it was published, and npm's registry is eventually consistent across CDN edges, so it intermittently fails with "no matching version" and a manual re-run fixes it. Adds two guards, because one is not enough: - Poll `npm view` until the version is visible, up to five minutes, before attempting the install. - Retry `npm install` up to five times anyway. `npm view` and `npm install` do not necessarily hit the same CDN edge, so the poll succeeding does not prove the install will resolve. `--prefer-online` revalidates rather than trusting a 404 cached by the failed attempt. The version is exported through GITHUB_ENV so the poll can see what the rewrite step computed. This does not remove the race, it waits it out. Building against the local `file:` SDK and rewriting the manifest only at publish time would remove it outright, since the bundle is identical either way, but that restructures a publish path that is awkward to test — this is the change that can be reasoned about when a release is half out. Not verifiable in CI: `publish-plugins` only runs on a release.
Deploying codex with
|
| Latest commit: |
3ebfbd9
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://679e680f.codex-asm.pages.dev |
| Branch Preview URL: | https://fix-npm-registry-propagation.codex-asm.pages.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
publish-pluginsintermittently fails with "no matching version" for@ashdev/codex-plugin-sdk, and a manual re-run fixes it.The cause is a race, not flakiness in the usual sense. The job rewrites each plugin's SDK dependency from
file:../sdk-typescriptto the versionpublish-sdkhas just pushed, then doesrm -rf node_modules package-lock.json && npm install. That install must resolve the SDK from the registry, seconds after publish. npm's registry is eventually consistent across CDN edges, so the version is not yet visible everywhere and the install fails.The fix
Two guards, because either alone leaves a hole:
npm viewuntil the version is visible, up to five minutes, before installing.npm installup to five times anyway.npm viewandnpm installdo not necessarily hit the same CDN edge, so the poll succeeding does not prove the install will resolve.--prefer-onlinerevalidates rather than trusting a 404 the failed attempt cached.The version is exported through
GITHUB_ENVso the poll can see what the rewrite step computed.What this does not do
It waits the race out rather than removing it. The alternative is to build against the local
file:SDK and rewrite the manifest only at publish time — the esbuild bundle is byte-identical either way, so the registry would never be consulted during the build and the race could not occur. That was the stronger option and it was considered; it restructures a publish path that cannot be exercised outside a real release, which is a poor trade against a job that already works on retry.Worth revisiting if the retries themselves start failing.
Verification
The poll predicate was validated against the live registry rather than assumed:
The workflow YAML parses and the step order is correct.
This cannot be verified by CI —
publish-pluginsonly runs on a release, so the first real exercise is the next tag.