[robobun]

Problem

• test/js/bun/css/css-fuzz.test.ts builds far fewer inputs than its generator tables contain, because the strategy switch (css-fuzz.test.ts:138-163 on main) indexes each generator's result with a fixed range that does not match the generators:
  • syntax indexes with Math.random() * 5, but unclosedRules returns a string (so the "input" is one character of it, a space or newline) and unclosedComments has 3 entries (indices 3 and 4 give undefined, which invalidCSS + "" turns into the stylesheet undefined). Measured over 100k picks: 13 of the 14 intended inputs, the whole unclosedRules sheet never, plus " " 20% of the time, "undefined" 10%, "\n" 5%.
  • structure indexes with Math.random() * 3, but malformedAtRules has 4 entries: @media screen and and {color:red} is never built (9 of 10).
  • encoding always takes [0]: 3 of its 38 inputs are built; 31 of the 32 controlCharacters variants never are.
• The assertions the file ends with do not check anything: crashCount (:189) only increments when an awaited Bun.build resolves to null/undefined, which it never does, so expect(crashCount).toBe(0) cannot fail, and the heapUsed < 500 MB check (:205) reads the JS heap while the bundler's work is native memory (it stays around 1 MB).
• invalidUTF8 (:54) runs its bytes through Buffer#toString(), so the parser receives U+FFFD replacement characters, which are valid UTF-8.
• The file is wrapped in if (!isCI), so none of its inputs run in CI.

Fix

• Every generator returns an array and the tables are flattened (inputsOf), so a generator's entry count no longer has to match a hard-coded index range. The file is typed satisfies Record<string, Record<string, () => string[]>> so a generator returning a bare string again fails to typecheck.
• Each generated input gets its own test (describe.each over strategies, test.each over the flattened inputs, named generator[i] <input>), and these run in CI: they are fixed inputs, so a failure is a deterministic parser regression. 62 tests, plus the 3 memory inputs on plain release builds; about 0.3s on release and 6s on a debug build. The random corruption loops pick from the same flattened lists and stay behind !isCI as before; they now always corrupt, since the uncorrupted inputs are covered by the table.
• expectBuildToFinish replaces crashCount and the heap check: every build runs with throw: false and has to end with exactly one output or with a non-empty logs. A parser crash takes the process down and a JS-level exception rejects the promise, so both still fail the test, and the check is one that can actually fail. The per-strategy errorCount > 0 assertion is gone with it: it was only ever a plumbing check, and the table checks every input's outcome individually.
• Inputs are byte strings and reach Bun.build via files as Buffer.from(css, "latin1"), so the three invalidUTF8 inputs are now the overlong sequences they claim to be (C0 80, E0 80 80, F0 80 80 80), all other inputs are ASCII and unaffected, and the string corruptions keep working on bytes. Test names escape bytes >= 0x7f as \xNN.
• Why this is safe to turn on in CI: all 65 inputs finish on both the release binary and a debug (ASAN) build at this base; so do 1174 enumerated corruption variants of the encoding inputs on both (every single corruption of all 38 inputs and every pair of corruptions of the three byte inputs, with every slice position enumerated rather than sampled). The memory strategy is gated on !isDebug && !isASAN (it was !isDebug): its 300-deep @media input overflows the parser thread's stack under ASAN (pre-existing, being fixed separately), which would otherwise hit the release ASAN lane now that the table runs in CI. That lane also runs this file without LeakSanitizer (it is already listed in test/no-validate-leaksan.txt), so only a crash or a failed assertion can turn it red, not a leak report. The file is part of the js/bun/css parallel batch; the table takes about 0.3s on a release build.
• Overlaps with test(css): stop css-fuzz.test.ts from writing invalid.css into the cwd #38491 (pass the sheet through files instead of writing invalid.css into the cwd) and test(css): replace the random css-fuzz loops with a deterministic table #38500 (fewer iterations on debug builds): this rewrite of the loop ends up including both, since the build call and the iteration table are the lines it replaces. Whichever lands second needs a trivial rebase; if this lands first the other two become no-ops.
• Test-only change, so there is no src diff to prove against; the evidence is the before/after on the same binaries:
  • USE_SYSTEM_BUN=1 bun test test/js/bun/css/css-fuzz.test.ts: 70 pass in 4.6s (10 runs in a row), versus 5 pass on main with the coverage above and a stray invalid.css left in the checkout.
  • bun bd test test/js/bun/css/css-fuzz.test.ts: 66 pass in 14s; main's file fails 4/4 on a debug build (timeouts, as described in test(css): replace the random css-fuzz loops with a deterministic table #38500).
  • CI=1 with both binaries: 65 pass (release, 0.3s) and 62 pass (debug, 6s); only the table runs.
  • Random loops on the debug build, 8 runs: no failures.

Background

• Bun.build({ files }) is an in-memory file map; an entrypoint whose path matches a key is bundled from the map instead of the disk, and values may be strings or byte arrays. The bundler asserts entry points are absolute, hence the fixed /css-fuzz/invalid.css key. throw: false makes a failed build resolve to { success: false, logs } instead of rejecting.
• The CSS tokenizer works on the raw bytes of the source, so invalid UTF-8 can only be exercised by handing it bytes; a JS string is always encoded to valid UTF-8 on the way in. Buffer.from(s, "latin1") maps each char U+0000..U+00FF of s to that single byte, which is how an ordinary string literal like "\xc0\x80" becomes the bytes C0 80.
• isASAN (test/harness.ts) is true for bun bd builds and for CI's release ASAN lane; isDebug only for the former.

Measurement of the old selection code

Replicating the three case bodies from main verbatim and counting distinct results over 100,000 picks per strategy (corruption step excluded):

=== syntax ===
intended base inputs: 14
distinct inputs actually built: 16 (13 of them are intended inputs)
intended inputs never built (1):
    "\n      .test { color: red\n      .another { padding: 10px }"
non-intended junk built:
    " " -> 20.0%
    "undefined" -> 10.0%
    "\n" -> 4.9%

=== structure ===
intended base inputs: 10
distinct inputs actually built: 9 (9 of them are intended inputs)
intended inputs never built (1):
    "@media screen and and {color:red}"

=== encoding ===
intended base inputs: 38
distinct inputs actually built: 3 (3 of them are intended inputs)
intended inputs never built (35): invalidUTF8[1..2], nullBytes[1..2], controlCharacters[1..31]

Outcome of the 65 uncorrupted inputs, identical on the release binary and the debug build: 15 rejected (unclosedRules, the 5 invalidSelectors, .test{:red}, @keyframes { @keyframes { } }, the 4 malformedAtRules, the 3 invalidImports), 50 built. None of the encoding or memory inputs is rejected, which is why the old errorCount > 0 for those strategies was only ever satisfied by the random corruptions (see #38500).

[coderabbitai]

Warning

Review limit reached

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

Next review available in: 19 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: a746f1ce-68e0-4337-a60d-52b660cc6249

📥 Commits

Reviewing files that changed from the base of the PR and between b9ef885 and 8d76aae.

📒 Files selected for processing (1)

• test/js/bun/css/css-fuzz.test.ts

---

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

[robobun]

Status: ready for review.

Reproduced the mis-indexing by replicating the three case bodies from main and counting distinct results over 100k picks (numbers in the PR body): syntax built 13 of 14 inputs plus " "/"undefined"/"\n", structure 9 of 10, encoding 3 of 38.

Verified on this branch (base b9ef885):

• USE_SYSTEM_BUN=1 bun test test/js/bun/css/css-fuzz.test.ts: 70 pass, 10 runs in a row
• bun bd test test/js/bun/css/css-fuzz.test.ts: 66 pass (main's file times out 4/4 on a debug build)
• CI=1 with both binaries: only the per-input table runs, 65 pass on release, 62 on debug

Overlaps #38491 and #38500 on the build call and iteration counts; whichever lands second is a trivial rebase.

[github-actions]

This PR may be a duplicate of:

1. test(css): stop css-fuzz.test.ts from writing invalid.css into the cwd #38491 - Changes the same and only file (test/js/bun/css/css-fuzz.test.ts) to replace the Bun.write("invalid.css") disk entrypoint with an in-memory files: { "/css-fuzz/invalid.css": ... } build, which this PR also does.
2. test(css): replace the random css-fuzz loops with a deterministic table #38500 - Edits the same iteration table in the same file for the same purpose: cutting per-strategy and mixed-input iteration counts on debug builds so the fuzz tests stop timing out.

🤖 Generated with Claude Code

[claude]

LGTM — well-reasoned test-only rewrite that fixes genuinely broken coverage.

What was reviewed:

• Verified Bun.build({ files }) accepts Buffer (typed as TypedArray) and isASAN is exported from harness.
• Checked that all non-invalidUTF8 generator inputs and all corruptCSS transforms stay in the ASCII range, so the latin1 encoding is byte-identical to what the old string path produced for them.
• Confirmed the memory-strategy gate (!(isDebug || isASAN)) keeps the known 300-deep @media ASAN stack overflow out of every CI lane now that the deterministic table runs there.
• expectBuildToFinish assertions can actually fail (unlike the old crashCount/heap checks), and the file no longer writes invalid.css into the checkout.

Extended reasoning...

Overview

Single-file rewrite of test/js/bun/css/css-fuzz.test.ts (test-only, no src/ changes). The old file was entirely wrapped in if (!isCI), mis-indexed its generator tables so most inputs (35 of 38 encoding inputs, the whole unclosedRules sheet, one malformedAtRules entry) were never built, wrote invalid.css into the cwd, decoded its "invalid UTF-8" bytes to U+FFFD before the parser saw them, and ended in assertions that could never fail (crashCount on a value Bun.build never returns; JS heap check for native memory). The rewrite flattens every generator into a labeled input list, runs each as its own test.each case in CI, keeps the random corruption loops behind !isCI with debug-scaled iteration counts, feeds inputs as Buffer.from(css, "latin1") through Bun.build({ files, throw: false }) so the overlong-UTF-8 bytes reach the tokenizer intact and nothing touches disk, and asserts each build ends with exactly one output or a non-empty logs.

Security risks

None. Test-only; inputs are static literals fed to the in-process bundler with no filesystem, network, or subprocess involvement.

Level of scrutiny

Moderate. The change is self-contained to one test file, but it does enable ~62 new tests in CI that previously never ran, so the main risk is CI breakage rather than correctness. The PR description shows the author ran the file across release, debug, debug+ASAN, and CI=1 configurations (and enumerated 1174 corruption variants of the encoding inputs) with all passing; the one known failure mode — the 300-deep @media ASAN stack overflow — is explicitly gated out via strategy !== "memory" || !(isDebug || isASAN). If any of the 62 fixed inputs did regress, CI would surface it deterministically on the first run.

Other factors

• files?: Record<string, string | Blob | NodeJS.TypedArray | ArrayBufferLike> in bun.d.ts:3150 confirms Buffer values are accepted; isASAN is exported at test/harness.ts:56.
• All generator inputs outside invalidUTF8 are ASCII (control chars 0x00–0x1F, null bytes, plain literals) and every corruptCSS transform stays in ASCII, so the switch to latin1 byte encoding does not change what those inputs deliver.
• The satisfies Record<string, Record<string, () => string[]>> constraint prevents the original bug (a generator returning a bare string) from recurring.
• Overlaps with #38491/#38500 are called out; whichever lands second is a trivial rebase. No CODEOWNERS entry covers this path and there are no outstanding human review comments.

[robobun]

Not a duplicate of #38491 or #38500, though it does overlap with both. Those two PRs fix the cwd write and the debug iteration counts and leave the input selection alone; this PR is about the selection itself (the [Math.random() * 5] / * 3 / [0] indexing that skipped most generator inputs), the crashCount/heapUsed checks that could not fail, and running the fixed inputs in CI. Rewriting that loop replaces the two lines they touch, which is why the same files: key and the same debug counts appear here. If either of them lands first this rebases on top of it; if this lands first they have nothing left to change.

[Jarred-Sumner]

Closing as a duplicate of #38500, which landed in #47025 (7942008).