npm publish loop is not resumable: a partial publish failure forces a version bump
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
调研方向
Locate the workflow step named npm-build-publish and inspect its platform publish loops, the PLATFORMS definition, and the hyperdb-api-node loop. First reproduce the current behavior from the workflow configuration and package paths. Done means a partial publish can be safely re-run, availability failures are detected, and platform definitions are not duplicated.
由索引模型根据 Issue 内容生成。
描述
Summary
The npm platform-package publish loops abort on the first already-published package, so a partial publish cannot be recovered by re-running the job. This turned a transient registry failure during v1.0.0-rc.2 into a situation with no re-run path.
What happened during v1.0.0-rc.2
npm-build-publish completed successfully — every job green, and the log shows a normal tarball summary plus the confirmation line + [email protected]. But that package never became available on the registry.
Confirmed absent by four independent routes, ~50 minutes after publish:
GET /hyperdb-mcp-linux-x64-gnu/1.0.0-rc.2→ 404- the full packument returns 200 and lists nothing newer than
1.0.0-rc.1 - that packages
rcdist-tag still points at1.0.0-rc.1 HEADon its tarball URL → 404, while the equivalent sibling URL → 200
Its siblings published immediately before and after it were both live within about five minutes. The likely cause is npms asynchronous post-publish processing silently failing to complete — the job log carries npms own "Your package is being processed and may take a few minutes to become available" warning, and this was the largest of the three tarballs at 87.4 MB compressed / 281 MB unpacked. The upload was accepted; the registry never finished making it available.
Why it cannot be re-run
set -euo pipefail
for dir in hyperdb-mcp/npm/darwin-arm64 hyperdb-mcp/npm/linux-x64-gnu hyperdb-mcp/npm/win32-x64-msvc; do
cd "$dir"
npm publish --access public --tag "$NPM_TAG"
cd -
done
darwin-arm64 is published first and already exists at 1.0.0-rc.2, so a re-run gets E403 You cannot publish over the previously published versions and set -e aborts the step before it reaches linux-x64-gnu. The hyperdb-api-node loop has the same shape.
So the only recovery paths are a manual one-off publish or cutting a new version — for a failure in a single package that the workflow itself reported as successful.
Impact of this instance
[email protected] is live and pins hyperdb-mcp-linux-x64-gnu at exactly 1.0.0-rc.2 in optionalDependencies, and the rc dist-tag now points at it. Because the dependency is optional, npm install hyperdb-mcp@rc on Linux x64 appears to succeed and then fails at launch with Could not find hyperdb-mcp binary for linux-x64. macOS arm64 and Windows x64 are unaffected, hyperdb-api-node published completely on all three platforms, and the latest tag still resolves to 0.7.3 — so only consumers who opt into @rc on Linux x64 are affected.
Suggested fix
Make each publish idempotent so the step is resumable, e.g. skip when the exact version already exists:
if npm view "$PKG@$VERSION" version >/dev/null 2>&1; then
echo "$PKG@$VERSION already published, skipping"
else
npm publish --access public --tag "$NPM_TAG"
fi
Two related hardening ideas worth considering in the same change:
- Verify availability, not just exit status. The step should poll the registry for each published version before declaring success, since this failure mode produces a zero exit code and a success log while the package is unreachable.
- Collapse the duplicated platform lists. The workflow comment states
PLATFORMSis "the SINGLE source of truth for which platforms ship", but the publish loops then hardcode the same three paths again — so there are two sources that must be kept in step. Driving the loops fromPLATFORMSwould remove the drift risk the comment warns about.
- 主要语言
- Rust
- 星标
- 3
- 派生
- 2
- 平均合并
- 2 天 6 小时
- 30 天内合并 PR
- 34
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
tableau/hyper-api-rust 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
tableau/hyper-api-rust#294 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 35/100
tableau/hyper-api-rust#311 ·
维护者通常 2 天内回复
-
难度 4/5 3-5 天 新手友好度 45/100
tableau/hyper-api-rust#305 ·
维护者通常 2 天内回复
-
Windows Named Pipe: verify DACL denies other users, and measure read-path perf for MCP workloads未关闭
难度 4/5 3-5 天 新手友好度 38/100
tableau/hyper-api-rust#302 ·
维护者通常 2 天内回复
-
难度 3/5 1-2 天 新手友好度 72/100
tableau/hyper-api-rust#300 ·
维护者通常 2 天内回复
查看 tableau/hyper-api-rust 的全部 Issue
相似的 Issue
-
area::tern-sync kind::cleanup triage::ready
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
review-bot
难度 2/5 1-3 小时 新手友好度 64/100
midagedev/bloomery#160 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 62/100
oxidecomputer/humility#737 ·
-
难度 1/5 1 小时以内 新手友好度 65/100
-
难度 2/5 1-3 小时 新手友好度 75/100
维护者通常 1 天内回复