[GH-ISSUE #1137] fix(process): cold macOS ownership-helper compilation exhausts source-map CLI deadlines #405

New issue

Closed

opened 2026-10-15 18:24:48 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-15 18:24:48 +00:00

Owner

Originally created by @MegaPhoenix92 on GitHub (Oct 8, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1137

Summary

On macOS, the focused webSourceLocationCli acceptance case consistently exceeds its 15-second owned subprocess deadline while the production operation is preparing the native process-ownership reader. The source-map codec does not hang: the outer test harness sends SIGTERM at 15 seconds, and REA returns a typed cancelled result with cleanup: complete.

The cold path compiles bridge/process/ProcessRunTokenReader.swift and ProcessRunTokenReaderMain.swift into a fresh temporary directory before launching the codec. Two independent executions of that exact compilation took 18.50 seconds and 18.40 seconds on the affected host. The test deadline is therefore shorter than a valid cold prerequisite, and the production source-map decode deadline is only 20 seconds, leaving little headroom.

Environment

Checkout: 0639a541a3b712940119f59e8189bc962b267726
macOS arm64
Node.js 24.18.0
npm 11.16.0
Vitest 5.0.3
Optional Hopper, Ghidra, and IDA providers absent and not involved

Reproduction

Build the checkout, then run the exact acceptance file with the pinned runtime:

PATH=/absolute/path/to/node-v24.18.0/bin:$PATH \
  ./node_modules/.bin/vitest run \
  --project acceptance \
  tests/acceptance/webSourceLocationCli.test.ts \
  --reporter=verbose

Observed consistently:

tests/acceptance/webSourceLocationCli.test.ts ... 15021ms
Error: Test process exceeded its 15000ms deadline

The captured child result was:

{
  "exitCode": 143,
  "signal": null,
  "stdout": {
    "code": "cancelled",
    "category": "cancelled",
    "details": {
      "operation": "trace_web_source_location",
      "cleanup": "complete"
    }
  },
  "stderr": ""
}

Measure the prerequisite independently using the same arguments selected by DarwinProcessRunTokenReader:

probe_dir=$(mktemp -d)
/usr/bin/time -p /usr/bin/xcrun swiftc \
  -module-cache-path "$probe_dir/modules" \
  bridge/process/ProcessRunTokenReader.swift \
  bridge/process/ProcessRunTokenReaderMain.swift \
  -o "$probe_dir/reader"

Two fresh measurements:

real 18.50
user 17.76
sys  0.66

real 18.40
user 17.69
sys  0.66

Cause

spawnOwnedProviderProcess calls prepareProcessOwnershipInspection before spawning the source-map codec. On Darwin, the process-global ownership host lazily calls createDarwinProcessRunTokenReader().prepare(). That reader invokes xcrun swiftc with a new temporary module cache and deletes the compiled helper when the REA process exits.

The acceptance invocation starts a fresh production CLI process and gives it 15 seconds. The harness therefore terminates the CLI before the 18+ second cold helper compilation can complete. Signal cancellation is handled correctly and cleanup completes.

There are two related contract problems:

The acceptance subprocess deadline is 15 seconds, but the production source-map decode limit is 20 seconds, so the test can terminate a still-valid operation before its own declared limit.
The native helper compilation consumes roughly 18.4 seconds inside that 20-second operation budget on this host, leaving insufficient headroom for the codec and ordinary contention.

Expected behavior

A supported cold macOS CLI operation should not be terminated by its acceptance harness before the operation's own declared deadline.
Native ownership preparation should have enough budget and lifecycle design to tolerate a representative cold Swift compilation without making short codec work appear hung.
Tests should exercise the real cold boundary and distinguish ownership-helper preparation from codec execution and cleanup.

Simply increasing the acceptance timeout would avoid the immediate failure but would not address the repeated per-process compilation cost or the narrow production deadline margin.

Duplicate search and distinction

Open and closed issues were searched for swiftc, process-token/ownership reader, source-map timeout, acceptance timeout, and cold start. The nearest result is #441, which covered eager JavaScript module loading before MCP initialization and was closed by #442. This failure is later, operation-scoped native helper compilation in a one-shot CLI process, not MCP entrypoint import or initialization.

Restoration check

On a cold macOS process boundary:

Run the focused acceptance file without prewarming native compilation state.
Confirm the valid source-map result is returned and CLI/MCP parity still passes.
Record ownership-helper preparation separately from codec execution.
Confirm cancellation during either phase still returns typed cancellation and cleanup: complete without leaving the helper compiler, codec, or temporary runtime alive.
Retain a slow/cold compilation case so the regression cannot be hidden by filesystem or module-cache warmth.

Triage assessment

Impact level: P2
Assessment status: supported
Evidence provenance: observed and source-traced
Local verification: reproduced twice at the helper boundary and once through the exact acceptance case
Workaround: warm/direct paths may complete quickly, but they do not cover the failing cold one-shot process boundary

Originally created by @MegaPhoenix92 on GitHub (Oct 8, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1137 ## Summary On macOS, the focused `webSourceLocationCli` acceptance case consistently exceeds its 15-second owned subprocess deadline while the production operation is preparing the native process-ownership reader. The source-map codec does not hang: the outer test harness sends SIGTERM at 15 seconds, and REA returns a typed `cancelled` result with `cleanup: complete`. The cold path compiles `bridge/process/ProcessRunTokenReader.swift` and `ProcessRunTokenReaderMain.swift` into a fresh temporary directory before launching the codec. Two independent executions of that exact compilation took 18.50 seconds and 18.40 seconds on the affected host. The test deadline is therefore shorter than a valid cold prerequisite, and the production source-map decode deadline is only 20 seconds, leaving little headroom. ## Environment - Checkout: `0639a541a3b712940119f59e8189bc962b267726` - macOS arm64 - Node.js 24.18.0 - npm 11.16.0 - Vitest 5.0.3 - Optional Hopper, Ghidra, and IDA providers absent and not involved ## Reproduction Build the checkout, then run the exact acceptance file with the pinned runtime: ```sh PATH=/absolute/path/to/node-v24.18.0/bin:$PATH \ ./node_modules/.bin/vitest run \ --project acceptance \ tests/acceptance/webSourceLocationCli.test.ts \ --reporter=verbose ``` Observed consistently: ```text tests/acceptance/webSourceLocationCli.test.ts ... 15021ms Error: Test process exceeded its 15000ms deadline ``` The captured child result was: ```json { "exitCode": 143, "signal": null, "stdout": { "code": "cancelled", "category": "cancelled", "details": { "operation": "trace_web_source_location", "cleanup": "complete" } }, "stderr": "" } ``` Measure the prerequisite independently using the same arguments selected by `DarwinProcessRunTokenReader`: ```sh probe_dir=$(mktemp -d) /usr/bin/time -p /usr/bin/xcrun swiftc \ -module-cache-path "$probe_dir/modules" \ bridge/process/ProcessRunTokenReader.swift \ bridge/process/ProcessRunTokenReaderMain.swift \ -o "$probe_dir/reader" ``` Two fresh measurements: ```text real 18.50 user 17.76 sys 0.66 real 18.40 user 17.69 sys 0.66 ``` ## Cause `spawnOwnedProviderProcess` calls `prepareProcessOwnershipInspection` before spawning the source-map codec. On Darwin, the process-global ownership host lazily calls `createDarwinProcessRunTokenReader().prepare()`. That reader invokes `xcrun swiftc` with a new temporary module cache and deletes the compiled helper when the REA process exits. The acceptance invocation starts a fresh production CLI process and gives it 15 seconds. The harness therefore terminates the CLI before the 18+ second cold helper compilation can complete. Signal cancellation is handled correctly and cleanup completes. There are two related contract problems: 1. The acceptance subprocess deadline is 15 seconds, but the production source-map decode limit is 20 seconds, so the test can terminate a still-valid operation before its own declared limit. 2. The native helper compilation consumes roughly 18.4 seconds inside that 20-second operation budget on this host, leaving insufficient headroom for the codec and ordinary contention. ## Expected behavior - A supported cold macOS CLI operation should not be terminated by its acceptance harness before the operation's own declared deadline. - Native ownership preparation should have enough budget and lifecycle design to tolerate a representative cold Swift compilation without making short codec work appear hung. - Tests should exercise the real cold boundary and distinguish ownership-helper preparation from codec execution and cleanup. Simply increasing the acceptance timeout would avoid the immediate failure but would not address the repeated per-process compilation cost or the narrow production deadline margin. ## Duplicate search and distinction Open and closed issues were searched for `swiftc`, process-token/ownership reader, source-map timeout, acceptance timeout, and cold start. The nearest result is #441, which covered eager JavaScript module loading before MCP initialization and was closed by #442. This failure is later, operation-scoped native helper compilation in a one-shot CLI process, not MCP entrypoint import or initialization. ## Restoration check On a cold macOS process boundary: 1. Run the focused acceptance file without prewarming native compilation state. 2. Confirm the valid source-map result is returned and CLI/MCP parity still passes. 3. Record ownership-helper preparation separately from codec execution. 4. Confirm cancellation during either phase still returns typed cancellation and `cleanup: complete` without leaving the helper compiler, codec, or temporary runtime alive. 5. Retain a slow/cold compilation case so the regression cannot be hidden by filesystem or module-cache warmth. ## Triage assessment - Impact level: P2 - Assessment status: supported - Evidence provenance: observed and source-traced - Local verification: reproduced twice at the helper boundary and once through the exact acceptance case - Workaround: warm/direct paths may complete quickly, but they do not cover the failing cold one-shot process boundary

bsakaguchi

2026-10-15 18:24:48 +00:00