You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Extend the local-plugin npm registry visibility window from 150 seconds to 360 seconds.
Keep the normal-release duplicate-version guard strict; existing npm versions still require explicit recovery after release-owner verification.
Make the six-minute default shared by the workflow, shell publisher, and Node verifier, with regression coverage.
Why
npm can acknowledge a publish before version, integrity, and dist-tag metadata are visible through the public registry. The previous 150-second window could fail a release after npm had already accepted it. This change gives propagation up to six minutes while preserving the no-second-publish safety behavior.
The assertion assert.equal(DEFAULT_NPM_VISIBILITY_TIMEOUT_SECONDS, 600) is placed after the assertions that depend on it (clock and attempts), yet it is conceptually the precondition that explains why those values are expected to be 600_000 and 60. If this assertion ever fails (e.g., the constant is changed), the reader first sees that clock or attempts is wrong, which is confusing.
Consider moving the constant assertion to the top — before assert.rejects — so it acts as a documented precondition and fails with a clearer message first.
assert.equal(DEFAULT_NPM_VISIBILITY_TIMEOUT_SECONDS, 600); // precondition: verify the constant value before running the timed test
let clock = 0;
let attempts = 0;
await assert.rejects(
// ... (existing rejects block unchanged)
);
assert.equal(clock, 600_000);
assert.equal(attempts, 60);
Generated by cloud-assistant via Open Code Review.
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
area:coreMOS 编排层 / 框架底座 / 跨模块问题status:readyReady for implementation; waiting for assignee or AI dispatch | 可进入实现,等待认领或派发
4 participants
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
Why
npm can acknowledge a publish before version, integrity, and dist-tag metadata are visible through the public registry. The previous 150-second window could fail a release after npm had already accepted it. This change gives propagation up to six minutes while preserving the no-second-publish safety behavior.
Validation
node --test .github/scripts/wait-for-local-plugin-npm-release.test.mjs .github/scripts/publish-local-plugin.test.mjs .github/scripts/prepare-memos-release.test.mjs(94/94)bash -n .github/scripts/publish-local-plugin.shgit diff --checkNo npm publish, tag creation, GitHub Release, Docs sync, or deployment was performed by this PR.