[chaliy]

What changed

The x86_64-apple-darwin cross build in js.yml's callback-platforms job
retries up to three times. Only the build is retried; the tests are not.

Why

The lane I added in #2780 is flaky, and since js-check gates on
callback-platforms, a toolchain crash blocks unrelated PRs. It already did:
#2787, a GitHub Actions version bump that touches none of this, is red on
it right now.

Cross-linking to x86_64 on the arm64 runner intermittently dies with:

error: linking with `cc` failed: exit status: 1
clang: error: unable to execute command: Segmentation fault: 11
clang: error: linker command failed due to signal (use -v to see invocation)
error: could not compile `getrandom` (build script) due to 1 previous error

It is the toolchain crashing, not our configuration:

• It fails while linking a build script — a host arm64 binary, so no
  cross-compilation flag of ours is in play. crates/bashkit-js/.cargo/config.toml
  only sets rustflags for x86_64-pc-windows-msvc.
• It picked a different crate each time: libc on one run, getrandom on
  another.
• It recurred after fix(js): unblock npm release by sizing the host-callback timeout for Rosetta #2780 scoped the Rust cache per target, and again on
  chore(ci): bump the github-actions group across 1 directory with 4 updates #2787 under a different Swatinem/rust-cache revision (so, a cold cache).
  Cache contamination was my first guess and it is ruled out.

Roughly two runs in five.

Before / After

commit	cross build	lane
75a810b (#2780)	segfault linking libc	fail
ea3bd4e (#2780)	ok	pass
6bf1fc2 (#2780)	ok	fail (intended — 2s experiment)
b4d9e70 (#2780)	ok	pass
1dc7911 (main)	ok	pass
9fcc382c (#2787)	segfault linking getrandom	fail

After: the first two attempts may crash and the job still succeeds. cargo
keeps whatever already compiled, so a retry resumes rather than rebuilds, and
each retry logs a ::warning:: so the flake stays visible rather than being
silently swallowed.

Risk

• Low, and it narrows rather than widens what passes. A genuine compile
  error fails all three attempts and still fails the job. The test step is
  outside the loop, so the regression the lane exists to catch — verified in
  fix(js): unblock npm release by sizing the host-callback timeout for Rosetta #2780 by reverting the budget to 2s — still fails it.
• A retry costs build time only on a run that would otherwise have failed
  outright.
• If the segfault rate climbs far enough that three attempts stop being
  enough, the lane's cost should be reweighed against its value rather than
  the retry count raised again.

Checklist

• Tests added or updated — n/a, CI configuration; the lane's own test
  coverage is unchanged
• Backward compatibility considered

---

Generated by Claude Code