Retry bun run build on the release path

[NiveditJain]

Follow-up to #726, found by the v1.0.1 release it unblocked.

What happened

The daemon-build fix from #726 worked — all four legs went green in the real release path, including the x86_64-unknown-linux-musl leg that had hung through three runner re-dispatches that morning (2.2m). The release then died one job later, on something else entirely:

✓ Compiled successfully in 14.4s
  Running TypeScript ...
panic: Segmentation fault at address 0x13CB0
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
error: Failed to run "next" due to signal SIGILL
error: script "build" exited with code 132

bun --bun next build segfaulted inside bun 1.3.14 during cli-tarball's Build step. Nothing about the code being released was wrong: the identical command had passed on the identical commit in ci.yml's build job minutes earlier. That is the definition of a retryable failure.

Because cli-tarball is upstream of everything, release-assets, publish, verify-install and announce all skipped. A stable release lost to a crash in the toolchain.

The gap

ci.yml's build job has wrapped bun run build in nick-fields/retry (3 attempts) since it was written. publish.yml's two bun run build steps had no wrapper at all:

Workflow	Job	Step	Retries
ci.yml	build	Build	3
publish.yml	cli-tarball	Build	none
publish.yml	publish	Build the tarball contents	none

So the path where a spurious failure costs the most was the one without a net — and the asymmetry was invisible until it fired.

The publish job's build is the worse of the two. By the time it runs, the release assets are already attached, so a crash there leaves a GitHub Release advertising daemon binaries whose npm package never shipped — exactly the "release pointing at something that does not exist" class release-pipeline.test.ts already guards the ordering against.

What changed

• nick-fields/retry@v4, max_attempts: 3, timeout_minutes: 10 on both publish.yml build steps — same wrapper, same budget as ci.yml.
• A drift guard in release-pipeline.test.ts: a bare run: bun run build anywhere in publish.yml now fails the suite, and any wrapped one must use nick-fields/retry with ≥2 attempts. This is the same shape as the other guards added in [luv-legion-725] Cut CI wall clock from ~4min to ~1.7min, and bound the jobs that can hang #726 — the failure mode is silent (a release is simply more fragile than CI), so it needs a test rather than a convention.

Scope note

This retries the flake; it does not pin bun. oven-sh/setup-bun@v2 uses bun-version: latest in all eight of its usages repo-wide, so the toolchain drifts under every workflow and 1.3.14 is simply what that resolved to that morning. Pinning is a broader, separate decision — it touches every workflow and changes what "latest" testing means — and three attempts is the proportionate fix for a nondeterministic segfault. Worth raising separately if this recurs.

Verification

• release-pipeline.test.ts green (51 tests, up from 50), and the new guard verified to fail against the pre-fix file shape.
• publish.yml parses; both steps confirmed wrapped via a YAML walk of every job's steps.

🤖 Generated with Claude Code

https://claude.ai/code/session_01KbT6esM8A8mkSymH13keLt

Hermes review

Field	Value
Status	Reviewing
Head	ae9d4a360ba6
Updated	2026-08-19T09:16:00.956413526+00:00

Codex is reviewing the current revision in an isolated nested-container harness.

[github-actions]

Thanks @NiveditJain for your contribution to Failproof AI! 🙌

We'd love to discuss your PR and welcome you to our community: https://discord.befailproof.ai/

[coderabbitai]

Warning

Review limit reached

@NiveditJain, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 16 minutes

Limit details: You’ve used all 4 included reviews currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 82d9748c-6a43-4a00-a4aa-09657133600e

📥 Commits

Reviewing files that changed from the base of the PR and between ce5116c and ae9d4a3.

📒 Files selected for processing (3)

• .github/workflows/publish.yml
• CHANGELOG.md
• __tests__/ci/release-pipeline.test.ts

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[hermes-exosphere]

Hermes

Status	Reviewing
Verdict	Not reviewed yet
Head	ae9d4a360ba6
Rounds	0 of 5

No summary yet.

What this changes

No component map for this revision.

Rounds

No review has finished on this pull request yet.

Findings

Nothing raised yet.

---

@hermes-exosphere help lists every command. This comment is maintained in place — I rewrite it after each review rather than posting a new one.