[robobun]

Problem

• bun bd test test/js/bun/css/css-fuzz.test.ts fails 4/4 on a debug build: the syntax, structure and encoding strategies hit this test timed out after 10000ms and "CSS Parser Mixed Input Fuzzing" hits timed out after 5000ms (main 032b8db; the release binary passes). Several recent CSS PRs list these timeouts as pre-existing noise from bun bd test test/js/bun/css/.
• Cause: each strategy builds 1000 (encoding: 500) randomly picked strings, one Bun.build call per string, and a Bun.build call costs 40-60ms on a debug build against the 10s timeout the file passes to test.each (css-fuzz.test.ts:226 on main).
• The random sampling is also what makes the file weak: the whole file is wrapped in if (!isCI) (css-fuzz.test.ts:115), so it registers no tests in CI, and the way the loop indexes its tables ([Math.floor(Math.random() * 5)] on every syntax generator at :144, * 3 at :153, [0] at :162) means 1000 iterations can only ever reach 28 of the 62 strings the tables define, three of them by accident ("\n", " " from indexing into the unclosedRules string, and the literal "undefined" from indexing past the 3-element unclosedComments array). The invalidUTF8 entries build the strings through Buffer#toString, which replaces the bytes with U+FFFD, so they were valid UTF-8 by the time the parser saw them.

Fix

• The file becomes a deterministic table: every string the old tables defined is built once as written and once more as a batch of the old corruptCSS transforms with the randomness removed (brace and colon/semicolon swaps, truncation, extra closing braces, reversal), the 32 control characters are built as one batch, the invalid UTF-8 sequences are passed as real bytes (spliced into a string token and into an identifier), and the two oversized generators (longSelectors, manyProperties) are fixed cases. 39 tests, 66 Bun.build calls.
• Each build asserts only that it came back well formed: every log has a string message, a successful build has one output per source, a failed one has at least one log. Which inputs the parser rejects is not asserted, since that changes on purpose as recovery improves; the file is a crash corpus, like doesnt_crash.test.ts next to it. A first test builds a valid stylesheet through the same helper so a broken files mapping fails loudly instead of turning the table into 66 resolution errors.
• Sources go through Bun.build({ files }), the in-memory input doesnt_crash.test.ts already uses, so the file no longer writes invalid.css into the cwd (test(css): stop css-fuzz.test.ts from writing invalid.css into the cwd #38491 fixes that write on the old loops; with this change there is nothing left to move, whichever lands first the other is a trivial rebase or becomes unnecessary).
• This removes the !isCI wrapper, the 10 * 1000 timeout, the iteration counts and the debug/release split, so there is nothing left to tune per build type: the tests take about 0.3s total on release and about 6s on a debug ASAN build (5.5s of that is the Bun.build calls, 0.7s the 500 KB selector), under the default per-test timeout by 5x or more for every test. Same approach as the fuzz ansi256 change in make some tests faster #33622: sweep the inputs the old loop was sampling instead of sampling them.
• test/no-validate-leaksan.txt loses its css-fuzz.test.ts line. The entry dates from when LSAN was wired up (45760cd), while the file registered no tests in CI; the rewritten file runs clean with the runner's LSAN settings (detect_leaks=1, BUN_DESTRUCT_VM_ON_EXIT=1, test/leaksan.supp) and with BUN_JSC_validateExceptionChecks=1 on the debug build.
• Dropped on purpose: the old memory.deepNesting generator (300 nested @media). It overflows the 4 MB pool-thread stack on debug/ASAN builds before MAX_NESTING_DEPTH applies, which is a parser bug with its own fix and test in ai slop #38481; the old file skipped the whole memory strategy on debug builds for this reason. Also left out: a stray continuation byte after a rule, which trips a char-boundary debug_assert in the tokenizer on debug builds; that is reported separately and gets its own test with its fix.
• Verified:
  • bun bd test test/js/bun/css/css-fuzz.test.ts: 39 pass (main: 0 pass, 4 fail, all by timeout).
  • USE_SYSTEM_BUN=1 bun test test/js/bun/css/css-fuzz.test.ts: 39 pass in 0.6s.
  • Debug build with the runner's LSAN and exception-check environment: 39 pass, exit 0, no sanitizer output.
  • On the release binary: 12 of the 27 strings are accepted as written (so they reach the printer) and 15 are rejected, all 27 corruption batches contain a rejected variant, and the control-character batch builds 32 outputs, so both branches of the helper's assertion run on every pass.
• Test-only change, so there is no src diff to stash for a before/after on the same test; the before is the current file timing out 4/4 under bun bd test, the after is the same command passing.

Background

• Bun.build({ files }) takes a map of path to contents and resolves entrypoints (and imports) against it before touching the disk, so a build can run entirely from memory; keys are normalized to forward slashes, which is why the test derives its virtual paths from import.meta.dir the same way doesnt_crash.test.ts does.
• throw: false makes Bun.build return { success, logs, outputs } for a failed build instead of throwing an AggregateError.
• When one source in a multi-entrypoint build is rejected, the bundler still parses every other source but stops before linking and printing, so the batch produces no outputs. That is why each string is also built alone: an accepted stylesheet then reaches the printer as well.
• test/no-validate-leaksan.txt lists test files the CI runner (scripts/runner.node.mjs) runs without LeakSanitizer on the ASAN lanes; everything else runs with detect_leaks=1 and the suppressions in test/leaksan.supp.

Runs

Main, debug build:

(fail) CSS Parser Invalid Input Fuzzing - syntax (1000 iterations) [10000.22ms]
(fail) CSS Parser Invalid Input Fuzzing - structure (1000 iterations) [10000.21ms]
(fail) CSS Parser Invalid Input Fuzzing - encoding (500 iterations) [10000.16ms]
(fail) CSS Parser Mixed Input Fuzzing [5000.15ms]
 0 pass, 4 fail
Ran 4 tests across 1 file. [37.82s]

This branch, debug build (bun bd test): 39 pass, 0 fail. Test bodies sum to 5.5s (median 115ms for the built-alone-plus-batch tests, 731ms for the 100000-part selector); a one-test file reports 3.7s on the same binary, which is the fixed startup cost.

This branch, release binary: 39 pass, 0 fail, Ran 39 tests across 1 file. [611.00ms].

Per-call cost measured with a standalone loop of Bun.build on a one-rule stylesheet, 100 iterations: release 1.2ms, debug 53-58ms.

Superseded first version of this PR

The first push kept the random loops and ran 50 iterations per strategy (10 for the mixed test) when isDebug, with a flake-rate argument for 50 (only ~23% of encoding iterations were rejected, so errorCount > 0 needed about 50 samples). Reviewing it showed the iteration count was the wrong knob: the coverage of the loops is bounded by their tables regardless of the count, the file was not running in CI at all, and enumerating the tables is both faster on a debug build than the tuned counts and removes the need for the split, so that version was replaced by the current one.

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 3 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 358e0496-e903-4c24-862d-51a198e7ccc9

📥 Commits

Reviewing files that changed from the base of the PR and between 032b8db and 499ac4e.

📒 Files selected for processing (2)

• test/js/bun/css/css-fuzz.test.ts
• test/no-validate-leaksan.txt

---

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

^{Updated 7:05 AM PT - Aug 14th, 2026}

❌ @robobun, your commit 959bd60 has some failures in Build #96005 (All Failures)

---

🧪   To try this PR locally:

bunx bun-pr 38500

That installs a local version of the PR into your bun-38500 executable, so you can run:

bun-38500 --bun

[robobun]

Status: ready for review (reworked since the first push, see below).

Reproduced on main 032b8db with bun bd test test/js/bun/css/css-fuzz.test.ts (debug build): 0 pass, 4 fail, all four by timeout. With this branch the same command passes 39/39 (about 6s of test time on the debug build), USE_SYSTEM_BUN=1 bun test test/js/bun/css/css-fuzz.test.ts passes 39/39 in 0.6s, and the file also passes on the debug build with the CI runner's LeakSanitizer and exception-check settings, which it now runs under because the !isCI gate is gone. Details and numbers are in the PR description.

[claude]

LGTM — test-only change that shrinks fuzz iteration counts under isDebug so the file fits its existing 10s timeout on debug builds; release counts are unchanged.

What was reviewed:

• Confirmed isDebug and log() were already imported/defined and used in this file, so this extends an existing pattern rather than adding a new knob.
• Checked the errorCount > 0 assertion against the 50-iteration encoding count — the ~0.77^50 flake analysis in the description holds; syntax/structure have higher error rates so 50 is comfortable there too.
• The whole file is gated behind if (!isCI), so CI coverage is unaffected either way; the only release-visible change is routing the mixed-test logs through log() so CSS_FUZZ_SHUTUP=1 silences them.

Extended reasoning...

Overview

Single-file, test-only change to test/js/bun/css/css-fuzz.test.ts. On debug builds (isDebug), the three per-strategy fuzz loops drop from 1000/1000/500 iterations to 50 each, and the mixed-input loop drops from 100 to 10. Release builds keep the original counts. The mixed test's two console.log calls are switched to the file's existing log() helper so CSS_FUZZ_SHUTUP=1 silences them like it already does for the other loop. A short comment explains why 50 (not fewer) is needed for the encoding strategy's errorCount > 0 assertion.

Security risks

None. No production code is touched; the file is a local-only fuzz test wrapped in if (!isCI).

Level of scrutiny

Low. This is a mechanical iteration-count adjustment using a predicate (isDebug) and a helper (log) that the file already imports and uses. It follows the review guidance to shrink the workload rather than raise the per-test timeout. Because the file never runs in CI, the change only affects developers running bun bd test locally, where it turns 4 hard timeouts into 4 passes.

Other factors

• The one non-trivial question is whether 50 iterations can flake on expect(errorCount).toBeGreaterThan(0). The description measures the encoding strategy at ~23% error rate (only the 30% randomly-corrupted iterations reject), giving ~0.77^50 ≈ 2×10⁻⁶ per run — well below flake threshold, and syntax/structure are far higher. This matches the code: the base encoding inputs are valid-ish CSS with odd bytes, and only corruptCSS (30% chance) turns them into parse errors.
• The memory strategy remains skipped on debug (pre-existing), and the PR calls out the underlying ASAN stack-overflow as a separate parser issue rather than papering over it here.
• No prior reviews or outstanding comments on the timeline; no bugs surfaced by the bug-hunting pass.

[robobun]

Reworked in 499ac4e: the first push only scaled the iteration counts down on debug builds. Looking at the loops more closely, the count was the wrong knob: the file registers no tests in CI (if (!isCI)), and its random indexing could only ever reach 28 of the 62 strings in its tables no matter how many iterations ran. The file is now a deterministic table of those strings (built as written and as a batch of fixed corruptions, through Bun.build({ files })), with the isCI gate, the timeout and the iteration counts removed, and it is taken off the LeakSanitizer skip list. 39 tests, about 0.3s on release and 6s on a debug build. The description has been rewritten for the current shape; the earlier review comments above refer to the superseded version.

[robobun]

#47025 lists #38491 and #38640 as duplicates of this PR. Both are still open. To check the overlap, I recorded every source that each version of css-fuzz.test.ts passes to Bun.build and compared the lists.

#38491 has nothing that this PR lacks. This PR builds 62 of the 65 fixed inputs of #38640 byte for byte. Two more differ only in whitespace (unclosedRules, manyProperties).

Inputs that only #38640 builds:

• memory.deepNesting: 300 nested @media screen { blocks around .test{color:red}. test(css): build every css-fuzz generator input instead of mis-indexing the tables #38640 builds it on release builds without ASAN only. The deepest block nesting in any source of this PR is 4.
• The variants from the random corruption loops, which test(css): build every css-fuzz generator input instead of mis-indexing the tables #38640 keeps for local runs and skips in CI. This PR removes the random loops by design, so these have no fixed counterpart here:
  • chains of 2 or 3 corruptions
  • the replacement of each [a-z] with a random letter
  • corrupted variants of the control character, invalid UTF-8 and oversized inputs
  • the mixed stylesheet (a valid rule, a corrupted rule, a valid rule)

One fact about deepNesting changed after the description above was written. The description points to #38481 for the fix and the test of that input. #38481 was closed without a merge. On main, the old file builds the input in local release runs only. I found no other test that nests blocks that deep: the deepest under test/js/bun/css is 150 levels (css.test.ts).

The input cannot go into this table as it is. A debug (ASAN) build of 367d939 ends with a segmentation fault at 200 and at 300 levels. It builds 100 levels, and the release build of the same commit builds 300 levels.

[Jarred-Sumner]

Landed in #47025 (7942008).

Test(css): replace the random css-fuzz loops with a deterministic table