[GH-ISSUE #1993] Darwin helper failure reported as timeout when the compiler actually errors #662

New issue

Closed

opened 2026-10-15 18:27:04 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-15 18:27:04 +00:00

Owner

Originally created by @EDMND-SRC on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1993

Observed on REA 6.4.0, macOS 14.8.9 x64, Command Line Tools 16.2 (before reinstall: a mismatched Swift and SDK pairing).

JavaScript analysis failed with macOS process ownership helper compilation failed via xcrun (compiler result: ETIMEDOUT) after 60000 ms. Direct reproduction of the exact invocation (xcrun swiftc on ProcessRunTokenReader.swift plus ProcessRunTokenReaderMain.swift) failed in about 23 seconds with exit 1 and concrete SDK mismatch errors, not a timeout.

Request: surface the compiler exit code plus bounded stderr in the helper failure, so toolchain breakage is distinguishable from a genuinely slow compile.

Originally created by @EDMND-SRC on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1993 Observed on REA 6.4.0, macOS 14.8.9 x64, Command Line Tools 16.2 (before reinstall: a mismatched Swift and SDK pairing). JavaScript analysis failed with macOS process ownership helper compilation failed via xcrun (compiler result: ETIMEDOUT) after 60000 ms. Direct reproduction of the exact invocation (xcrun swiftc on ProcessRunTokenReader.swift plus ProcessRunTokenReaderMain.swift) failed in about 23 seconds with exit 1 and concrete SDK mismatch errors, not a timeout. Request: surface the compiler exit code plus bounded stderr in the helper failure, so toolchain breakage is distinguishable from a genuinely slow compile.

bsakaguchi

2026-10-15 18:27:04 +00:00

closed this issue
added the
area: native

bug
labels

bsakaguchi commented

2026-10-15 18:27:04 +00:00

Author

Owner

@jimpablo commented on GitHub (Oct 12, 2026):

I'd like to work on this.

The reported text is built in src/process/DarwinProcessRunTokenReader.ts (runCompilation): the catch around the xcrun swiftc invocation keeps only cause.code and cause.message. At the 60 s deadline execFileOutput rejects with code ETIMEDOUT and the message Command timed out after 60000 ms: /usr/bin/xcrun, and any stderr the compiler produced before the deadline — the SDK-mismatch diagnostics in this report — is dropped: it is attached to the rejected error object but never read. A fast exit 1 failure only surfaces diagnostics incidentally through Node's default error text.

ExecFileOutput already attaches stdout/stderr to every rejection and exports execFileOutputFailure for exactly this; AdbConfiguration/ApktoolConfiguration already render exit_code plus a bounded stderr_excerpt from it.

Planned change, in the reader's failure mapping only:

Keep the ENOENT wording and the cancellation mapping unchanged.
Render the compiler outcome explicitly — exit code N, timed out after N ms, or the stop signal — followed by a bounded stderr excerpt (512 characters, truncation marked), or an explicit "no compiler diagnostics were captured" when nothing was captured.
Boundary tests with fake compilers for both paths: a fast failure with diagnostics, and a compiler that prints SDK-style errors and then stops responding until its deadline (a reduced compile deadline keeps the lane fast; the production default stays 60 s).

I cannot reproduce the mismatched-CLT hang on a healthy toolchain, so I will not claim a root cause for the 60 s-vs-23 s difference; this change makes whatever the compiler did print visible in both shapes.

@jimpablo commented on GitHub (Oct 12, 2026): I'd like to work on this. The reported text is built in `src/process/DarwinProcessRunTokenReader.ts` (`runCompilation`): the `catch` around the `xcrun swiftc` invocation keeps only `cause.code` and `cause.message`. At the 60 s deadline `execFileOutput` rejects with code `ETIMEDOUT` and the message `Command timed out after 60000 ms: /usr/bin/xcrun`, and any stderr the compiler produced before the deadline — the SDK-mismatch diagnostics in this report — is dropped: it is attached to the rejected error object but never read. A fast `exit 1` failure only surfaces diagnostics incidentally through Node's default error text. `ExecFileOutput` already attaches `stdout`/`stderr` to every rejection and exports `execFileOutputFailure` for exactly this; `AdbConfiguration`/`ApktoolConfiguration` already render `exit_code` plus a bounded `stderr_excerpt` from it. Planned change, in the reader's failure mapping only: - Keep the ENOENT wording and the cancellation mapping unchanged. - Render the compiler outcome explicitly — `exit code N`, `timed out after N ms`, or the stop signal — followed by a bounded stderr excerpt (512 characters, truncation marked), or an explicit "no compiler diagnostics were captured" when nothing was captured. - Boundary tests with fake compilers for both paths: a fast failure with diagnostics, and a compiler that prints SDK-style errors and then stops responding until its deadline (a reduced compile deadline keeps the lane fast; the production default stays 60 s). I cannot reproduce the mismatched-CLT hang on a healthy toolchain, so I will not claim a root cause for the 60 s-vs-23 s difference; this change makes whatever the compiler did print visible in both shapes.

bsakaguchi referenced this issue

2026-10-15 18:28:32 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:14:52 +00:00

[PR #662] [MERGED] test(hopper): synchronize startup cancellation with launcher readiness #2145