Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

npm publish loop is not resumable: a partial publish failure forces a version bump

Đang mở
  • Có gì không ổn?
#269 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
node.js, shell
Lĩnh vực
ci-cd, release

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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 rc dist-tag still points at 1.0.0-rc.1
  • HEAD on 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:

  1. 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.
  2. Collapse the duplicated platform lists. The workflow comment states PLATFORMS is "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 from PLATFORMS would remove the drift risk the comment warns about.
Ngôn ngữ chính
Rust
Star
3
Fork
2
Merge trung bình
23 giờ 11 phút
Pull request đã merge (30 ngày)
65

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của tableau/hyper-api-rust

Tất cả issue của tableau/hyper-api-rust

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.