Repository navigation
Keep NUL bytes out of the build-agent log test output - #392
Merged
Merged
Conversation
Two build-agent log tests flood record() with NUL-only lines. record() mirrors every line to process.stderr, so each run printed about 66,000 NUL bytes into the platform-unit output. In CI these showed up as thousands of ^@ lines and buried the real failure. Stub process.stderr.write only around the two NUL loops. The tests check the log ring and the /logs body, never stderr, so what they assert does not change. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
🚀 Deploying Preview to Cloudflare 🚀Preview URL: https://fix-platform-unit-nul-output-void-cloud.voidzero-docs.workers.dev (commit 995d7e5)This URL reflects your latest Preview deploymentPreview Deployments by commit
|
Brooooooklyn
added a commit
that referenced
this pull request
Oct 8, 2026
## Problem `test (platform-unit)` sometimes dies on Linux with exit code 132, and no test fails. Node 24's V8 aborts while it frees PGlite's WebAssembly code in a worker thread: ``` # Fatal error in , line 0 # Check failed: jit_page_->allocations_.erase(addr) == 1. v8::internal::ThreadIsolation::UnregisterWasmAllocation Process completed with exit code 132. ``` ``` platform-unit (pool: threads, one process) ├─ worker: build-manager.test.ts ✓ ├─ worker: github-authority-migration (PGlite) finishes │ └─ V8 frees its Wasm code ──► fatal check ──► SIGILL └─ whole Vitest process dies ──► no summary, no failing test name ``` `platform-unit` runs every file as a worker thread in one Vitest process. When one thread hits this V8 check, the whole process dies. Five platform unit files start PGlite. `bffa88e28` fixed the same abort for the API integration project: it runs those files in forks on Linux. That fix did not cover the PGlite files in `platform-unit`. Seen on Oct 8: - run 37742762058: 0.9 s after `github-authority-migration.test.ts` finished, with three PGlite files not yet reported. - run 37754922940 (#392): exit 132 two seconds into the run. ## Fix Move the five PGlite files into a new project, `platform-unit-pglite`. It uses forks on Linux and threads on other platforms. The other 138 platform unit files stay on threads. ``` before: platform-unit (threads) ── 143 files, PGlite included after: platform-unit (threads) ── 138 files platform-unit-pglite ── 5 PGlite files, forks on Linux ``` - CI already runs `--project 'platform-unit*'`, so it selects both projects. - `vp run test --unit` (`test/affected.mjs`) and `test:platform` (`platform-*`) include the new project. - A config test fails if a new platform unit file that imports PGlite is not in `platform-unit-pglite`. - The test bodies do not change. The crash does not reproduce on demand. In Linux Docker with Node 24.21.0, a standalone script ran more than 3,000 PGlite worker teardowns and did not abort. The fix follows where the CI crashes happened and the earlier fix in `bffa88e28`. ## Testing - `vp test run packages/void/test/unit/test-projects.test.ts`: 5 passed. - `vp test run --project 'platform-unit*'`: 143 files, 2701 tests passed. - With the platform faked: Linux puts `platform-unit-pglite` on forks. macOS and Windows keep threads. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When
test (platform-unit)fails in CI, the log hides the failure under thousands of^@lines.record()writes a copy of each line toprocess.stderr. Two tests fill the log buffer with NUL-only lines to test the byte budgets. Each run printed about 66,000 NUL bytes, and local runs print them too. In a failed CI run, these bytes buried the real error.Fix
Stub
process.stderr.writeonly around the two NUL loops, and restore it infinally./logsbody. They never check stderr, so what they test does not change.true, so the backpressure latch inrecord()does not change.Testing
vp test run platform/packages/api/test/unit/build-manager.test.ts: 315 passed.🤖 Generated with Claude Code