Build SEA binary (document-mcp, windows-latest) failed once with no task error in the log

[Mearman]

On the push-to-main run for the byte-codec feat merge (run 35500796752, sha 6061c9f), the job "Build SEA binary (document-mcp, windows-latest)" (job 106054353517) failed at the step "Build the released package's SEA bundle". Every other job in that run passed.

The log shows pnpm --dir "packages/document-mcp" build running turbo run _build, the task groups for excel-number-format, byte-codec, document-schema.js, archive-codec, markdown-codec and epub-codec all finishing normally (epub-codec ends with "Build complete in 8700ms"), and then [ELIFECYCLE] Command failed with exit code 1. with no error text from any task. The output of the task that failed isn't in the log at all.

The same job passed on the runs either side of it (35498974119, 35498312775 before, and 35502792225 after, all on windows-latest for document-mcp), so it isn't a steady failure, but I couldn't establish why it failed once. Nothing in that push touched document-mcp, and its dependency on byte-codec is unchanged at that point.

If it happens again it needs the failing task's own output. Turbo prints each task's group only when it completes, so it may be worth running the SEA build with --output-logs=full or --log-order=stream so a task killed mid-way still shows its last lines.

[Mearman]

Same thing again on main, different package: Build SEA binary (document-rest, windows-latest) in https://github.com/ExaDev/documents.js/actions/runs/35518207799/job/106100014952, on commit 7ed643f.

Identical signature. The last build in the log finishes cleanly ("Build complete in 8669ms"), then one second later the step ends with [ELIFECYCLE] Command failed with exit code 1. and ##[error]Process completed with exit code 1. and nothing else. Grepping the whole 4294-line log for an error, a missing module, EPERM/EBUSY, or anything from postject turns up nothing at all. The windows-11-arm job for the same package in the same run passed, and so did every other SEA job.

The Release job in that run succeeded and everything published, so this only cost the one binary.

[Mearman]

Dug into both occurrences. The short version: nothing fails. Turbo stops mid-graph, right after a task that succeeded, and pnpm reports the exit code.

The failing step is not the SEA injection. It is Build the released package's SEA bundle, which is pnpm --dir "packages/<name>" build, so turbo run _build over that package's dependency graph.

Taking the second occurrence (run 35518207799, job 106100014952, document-rest, windows-latest) against the job that passed beside it in the same run (job 106100014906, document-mcp, windows-latest):

• The failing job ran six _build tasks: excel-number-format, byte-codec, document-schema.js, archive-codec, markdown-codec, epub-codec. The sixth finished normally, printing its full tsdown output and Build complete in 8669ms, then ##[endgroup]. 1.05 seconds later: [ELIFECYCLE] Command failed with exit code 1. and ##[error]Process completed with exit code 1.
• No turbo summary line at all. No Tasks: N successful, no Failed: line, no task error.
• The passing job ran seventeen tasks through to a normal turbo summary.
• Same runner image (provisioner 20260828.587), same runner version (2.337.0), same turbo run _build invocation with TURBO_FLAGS empty, and the task hashes for the shared packages are identical between the two jobs (2ec9266d7f5be86d, 92fa5a01a99ae2b7, a1a1a3563b500571, 16d9e69e33059a54, 4bec75d65c05fb12, 00b0cd4935dc5101).

So it is not package-specific: document-mcp failed in the first occurrence and passed in the second, and document-rest did the reverse.

On the "output lost to turbo's log grouping" theory: I do not think anything is being lost, because every task that started also finished successfully and printed its own output in full. There is no failing task whose output could go missing. Grepping all 4294 lines of the failing log finds no npm error, no Cannot find, no EPERM, EBUSY, EMFILE or MODULE_NOT_FOUND, nothing from postject, and no path-length complaint. The only annotation on the job is the generic Process completed with exit code 1.

That leaves turbo itself exiting non-zero during or just after its sixth task, in a run where the remaining eleven tasks never start.

On reproducing it: the SEA job can be driven without re-running a release, via workflow_dispatch with backfill_tags (the job's if takes collect-backfill-matrix as an alternative to release, and it checks out the tag). But the same dispatch also runs the npm alias republish and the GitHub Packages mirror for that tag, so it is not a no-publish reproduction and I have not run it.

The cheap way to catch the next one is to make that one step say what turbo was doing: pnpm --dir "packages/${{ matrix.name }}" build -- --output-logs=full --verbosity=2. I have not changed ci.yml, since that file is being worked on elsewhere; whoever owns it can take the line.

[Mearman]

Capture is in place on main (#1343). Still open, because this catches the failure rather than fixing it.

What the SEA build step now does, on every matrix entry:

• Builds with --output-logs=full --verbosity=2 --summarize. The summary is the part that matters: turbo writes its own record of what it planned against what it actually executed, which is the distinction neither existing log can make.
• On failure only, and placed immediately after the build so they fire for that step and nothing later: the runner's free disk and temp directory listing, the fifteen largest processes by working set on Windows, and the turbo run summary uploaded as an artifact named turbo-run-summary-<package>-<os>.

What to look at next time it goes red:

1. The run summary artifact. If it lists tasks as planned that have no execution record, turbo ended the run without attempting them, and the question is why turbo exited. If instead a task is recorded as failed, then something was being swallowed after all and the full output will now show it.
2. The disk figure. Both occurrences so far died a second after a build that writes a lot of dts output, so a full or nearly-full volume is worth ruling out first.
3. The Windows process list, for anything holding memory or a file handle at that moment.

The evidence from the two occurrences so far, for whoever picks this up: the failing step is pnpm --dir packages/<name> build, so turbo run _build, not the SEA injection. Turbo got through six tasks in the second occurrence, the sixth finished normally and printed its full output, and 1.05s later pnpm reported exit 1 with no summary and no task error. The job that passed beside it in the same run, same runner image, same invocation, identical task hashes for the shared packages, ran seventeen tasks to a normal summary. It is not package-specific: document-mcp failed in the first occurrence and passed in the second, document-rest did the reverse.