What happens
tests/test_next_app_route_dylib.sh fails at the first cold start when invoked from a working directory outside the repository:
perry: FATAL: unwind tables are missing from this runtime build (0 frame(s) visible to the unwinder).
Re-running the identical command from the repo root passes cleanly. Observed on 695daf302b (bench mini, macOS 26.5.1 arm64) during the #8040 acceptance run.
Why
The gate builds its provider runtime dylib with cargo build --manifest-path <worktree under $TMPDIR>/…. Cargo discovers .cargo/config.toml from the invoking working directory, not from the manifest path — and that file is the sole supplier of
[build]
rustflags = ["-C", "force-unwind-tables=yes"]
which #7302's exception transport requires: panic = "abort" omits unwind tables by default, so without the flag every throw crossing a runtime helper frame is stranded. Run from outside the repo, the provider runtime is built without unwind tables and the runtime's own self-check fires on the first try.
Why it is worth fixing rather than documenting
The failure names the wrong culprit. It reports a property of the runtime build ("unwind tables are missing") with no hint that the cause is the caller's cwd, and it appears at cold start 1 — i.e. after a ~25-minute compile — so the feedback loop is expensive. Anyone hitting it will reasonably suspect the runtime build, the profile, or #7302 itself before suspecting cd.
CI is unaffected (it runs from the repo root), which is exactly why this can sit latent.
Suggested fixes
- Have the script
cd to the repo root itself, or pass --config / set CARGO_BUILD_RUSTFLAGS explicitly for the provider build so the flag cannot depend on cwd. The script already computes repo_root.
- Optionally assert early: if the built provider runtime lacks unwind tables, fail before serving with a message naming the cwd/rustflags cause rather than letting the runtime's self-check surface it 25 minutes later.
Same class as the other cwd-sensitivity in this fixture family fixed by #8209 (the host previously ran from .next/server, which broke Next's per-request routes-manifest.json open).
What happens
tests/test_next_app_route_dylib.shfails at the first cold start when invoked from a working directory outside the repository:Re-running the identical command from the repo root passes cleanly. Observed on
695daf302b(bench mini, macOS 26.5.1 arm64) during the #8040 acceptance run.Why
The gate builds its provider runtime dylib with
cargo build --manifest-path <worktree under $TMPDIR>/…. Cargo discovers.cargo/config.tomlfrom the invoking working directory, not from the manifest path — and that file is the sole supplier ofwhich #7302's exception transport requires:
panic = "abort"omits unwind tables by default, so without the flag every throw crossing a runtime helper frame is stranded. Run from outside the repo, the provider runtime is built without unwind tables and the runtime's own self-check fires on the firsttry.Why it is worth fixing rather than documenting
The failure names the wrong culprit. It reports a property of the runtime build ("unwind tables are missing") with no hint that the cause is the caller's cwd, and it appears at cold start 1 — i.e. after a ~25-minute compile — so the feedback loop is expensive. Anyone hitting it will reasonably suspect the runtime build, the profile, or
#7302itself before suspectingcd.CI is unaffected (it runs from the repo root), which is exactly why this can sit latent.
Suggested fixes
cdto the repo root itself, or pass--config/ setCARGO_BUILD_RUSTFLAGSexplicitly for the provider build so the flag cannot depend on cwd. The script already computesrepo_root.Same class as the other cwd-sensitivity in this fixture family fixed by #8209 (the host previously ran from
.next/server, which broke Next's per-requestroutes-manifest.jsonopen).