[robobun]

Problem

• The dev server serves a file that the printer cannot print as empty code or as an empty stylesheet, with no error. Debug builds abort: debug_assert!(matches!(compile_result, CompileResult::Javascript { result: PrintResult::Result(_), .. })) in finalize_bundle.
• A rebuild frees a file the moment one of its imports fails (insert_stale_extra, src/runtime/bake/dev_server/incremental_graph.rs:1334). A linked stylesheet is then no CssRoot, but its route stays loaded. A page request before the rebuild ends gets no <link> for it. If the stylesheet has an @import, debug builds abort: panic: only CSS roots should be found by tracing.

Fix

• finalize_bundle records a part or a CSS chunk that failed to print as a per-file failure (insert_failure). A parse error takes the same path: error overlay, 500 for the route.
• A failed stylesheet keeps its CssRoot content, and its asset while the rebuild is in flight. The id is the hash of the path, so it stays valid. trace_imports collects a failure before the CSS check.
• Verified: test/bake/dev/bundle.test.ts (eleven new tests), test/js/bun/http/bun-serve-html.test.ts (one new test). Notes list the other suites.
• Self-reviewed: 12 concerns raised, 6 addressed. Notes name the other 6 with the reason.

Background

• The dev server keeps one File per path and one edge per import. File.failed marks a file with an error.
• A CSS root is a stylesheet that HTML links or a script imports, served as one chunk at /_bun/asset/<path hash>.css. A stylesheet that a root imports is a CssChild with no chunk.
• trace_imports with the FindCss goal collects the root ids of a route for its <link> list and stops at each root.

Notes

Merge of main and the page request during a rebuild

• The branch did not build on main: error[E0609]: no field first_dep on type &mut IncrementalGraph<SIDE>. dev server: keep a file's two edge list heads in one Vec #39151 moved the two edge list heads of a file into edge_lists. The walk in invalidate that used the field is removed (see Self-review).
• New test: page request while a rebuild that fails a linked stylesheet is in flight in test/js/bun/http/bun-serve-html.test.ts. An onResolve plugin parks the rebuild after @import "./missing.css" failed. The fixture then requests the page and every stylesheet that the page links. The HMR socket tells it when each rebuild has ended, so the test has no sleep. The same steps as a script give:

build	page during the rebuild
main 367d939, release canary	200, no <link>
main 367d939, debug	exit 134, panic: only CSS roots should be found by tracing
this branch, debug build	200, one <link>, the stylesheet answers 200 with the last good rules
this branch, release build	200, one <link>, the stylesheet answers 200 with the last good rules

• The debug stack on main: trace_imports (incremental_graph.rs:1236), called from trace_all_route_imports, generate_html_payload, on_html_request_with_bundle, ensure_route_is_bundled, respond_for_html_bundle.
• A framework route has the same window through generate_css_js_array (meta.styles). Probe with a route that imports the stylesheet. A debug build of main aborts with the same panic. The release canary answers styles: []. A debug build of this branch answers the stylesheet URL, and the URL answers 200. There is no test for this probe: it goes through the same trace_imports code.
• The asset of the stylesheet: insert_stale_extra dropped it together with the content, so the <link> of a page that is served during the rebuild answered 404. eb59386 keeps the asset of a CSS root there. The rebuild replaces it (replace_path) or insert_failure drops it when the rebuild ends.
• Not covered: a stylesheet that fails to parse. handle_parse_task_failure calls insert_failure before the rebuild ends, so the asset is gone at once. Probe: one batch breaks the syntax of a linked stylesheet and parks on an import of a second one. The page that is served in between keeps both <link>s, and the broken stylesheet answers 404 until the rebuild ends (debug and release build of this branch). After the rebuild the route answers the build failure page. The test does not cover this: the parse result comes from another thread, so the fixture cannot wait for it without a sleep.
• After a failed rebuild the URL of the stylesheet answers 404 until the next good build, as on main. An HTML route answers the build failure page in that state. dev server: fail a framework route when a stylesheet it imports fails to build #42872 covers a framework route that keeps its 200.

Self-review

Addressed in 9993ca1:

• invalidate had two walks that queued the failed dependents of an edited file. They date from a revision where a failed stylesheet had Unknown content. A failed stylesheet keeps CssRoot now, so the existing CSS root arm reaches it, and no test needed the walks. Their only effect left was to bundle a failed script or html file again on every save of a stylesheet that it imports. They are removed, so this PR no longer changes invalidate.
• trace_imports had a branch for a failed CssChild. It could not run: insert_failure leaves Unknown or CssRoot, and only insert_empty creates CssChild, for a new file. The function is the code of main again, with the FindErrors block moved before the CSS check.
• The test css resolution error with an edge adjustment passed on a release build without the fix. It now checks that the failed stylesheet keeps its place in the CSS list, like the parse error test. It fails on 1.4.2 with Selector '.fine' was not found.
• A comment in generateChunksInParallel.rs said that the dev server drops the code of a part that fails to print. It names the per-file failure now. A comment in finalize_bundle claimed more than the code does (a root that fails its first parse has no place in the CSS list), so it is the text of main again.
• The six CSS print tests depend on a second defect: the dev server prints a stylesheet with other targets than it was minified for, and only then do the nested :fullscreen rules fan out. bun build --target=browser prints the same file (1.26 KB). bake: minify stylesheets for browser targets in every graph #37051 and css: print a stylesheet with the targets StyleSheet::minify recorded #39251 make the two agree. After either of them these tests need another stylesheet that fails to print. I found none that fails under every target set: the mixed prefix shape of nested-vendor-prefix-duplication.test.ts fails in the minifier with browser targets, not in the printer. A comment at the first CSS test says so.
• An earlier text of this body said that all eleven tests fail without the fix. See Tests below for the correct counts.

Not taken:

• A stylesheet that fails to parse during a held rebuild still links a 404 (see above). The fix is to keep the asset in insert_failure too. Then nothing drops the asset of a CSS root any more, and unref_by_path and FreeCssMode::UnrefCss are dead code. That cleanup is a change of its own.
• On main and here: a CSS root that prints and then fails later in the same bundle (an onResolve plugin that rejects an @import) is sent to connected pages as an empty stylesheet, because insert_failure dropped the asset before the hot update is written. Read from the code, not run.
• On main and here: when two roots of one bundle import the same file, only the first root gets the edge (dev server: give every CSS root in a bundle its own edges to the files it imports #42697). An edit of the shared file then queues only that root.
• Four tests write two files in one batchChanges and need both in one bundle. hot.test.ts and css.test.ts use the same harness pattern.
• The two TOML tests take 9 to 21 s each on a debug build. The printer writes its indentation until the stack guard trips, and a shallower table does not trip it.
• No test covers the imported_on_server branch of a failed CSS chunk. A stylesheet that a server file imports is minified without browser prefixes, so the :fullscreen input prints there.

Related open PRs

• dev server: make a client script request wait for the bundle in flight #42733 makes the client script request wait for the rebuild, which is the script side of the same window. It changes failures_added.push to gts.failures.push in the FindErrors block that this PR moves. The merge must keep gts.failures.push: check_route_failures of dev server: make a client script request wait for the bundle in flight #42733 reads only that list.
• bake: consolidate the open robobun dev-server, HMR runtime, production build and router fixes #39488 carries the same gts.failures line and adds a loader argument to insert_failure. The three new calls in finalize_bundle need it. It does not carry this change.
• dev server: re-bundle the CSS root when a stylesheet it imports recovers from a failed build #42738 calls receive_inlined_css for every stylesheet that a chunk inlines, and that clears failed. With this PR, pass 2 also runs for a chunk that failed to print. If both land, receive_inlined_css must leave a failed CssRoot alone. Sequence: a page links main.css and sub.css, main.css imports sub.css, sub.css cannot be printed, and an edit of main.css alone would clear the failure of sub.css.
• dev server: make CSS module imports work under bun ./index.html #42058 adds a CssModule root. prior_css_root in insert_stale_extra and insert_failure matches CssRoot only, so whichever PR lands second has to cover the new variant.
• bake: minify stylesheets for browser targets in every graph #37051 and css: print a stylesheet with the targets StyleSheet::minify recorded #39251: see the CSS print tests under Self-review.

Repros for the print failure

Import a TOML file with "[" + "a.".repeat(100_000) + "a]\nd = 1\n" (the AST is too deep for the recursion guard of the printer), or link a stylesheet of 30 nested .xN:fullscreen { ... } rules (629 bytes of valid CSS, the per-prefix output trips the expansion guard of the CSS printer).

This is the dev server counterpart of #37036, which made bun build and Bun.build fail on a module that the printer cannot print. That PR excluded the dev server: its caller chain turns a linker error into an OOM panic, so a build-wide failure would stop the whole server on one bad file.

How the print failure is recorded

• JS parts: pass 1 of finalize_bundle builds a log with one message ("Maximum call stack size exceeded while generating code for this file" for a stack overflow, the printer error name otherwise). It calls insert_failure for the source file of the part, and not receive_chunk with empty code. Pass 2 skips the failed parts, because they have no resolved file index.
• CSS chunks: when a compile result of the chunk has an error, the failure goes on the entry point file of the chunk. That is the file receive_chunk registers, so a good rebuild clears it. The message names the file that failed when its source index is known. Pass 2 still runs for the chunk, so the @import edges stay and an edit of an imported file queues the chunk again.
• A failed CSS chunk is left out of the hot update payload. The stylesheet that the page already has stays active until the next good build.

Tests in test/bake/dev/bundle.test.ts

• client graph (HTML route, TOML module): the first load shows the error overlay with the message, recovery reloads and runs, a second break over a hot update serves the error page and shows the overlay again, and a second recovery works.
• server graph (framework route, TOML module): the broken module answers 500 with the error page, recovery serves the route.
• CSS (HTML route stylesheet): the first load shows the error overlay with "Failed to generate CSS for this file (PrintError)", recovery reloads and applies the fixed stylesheet.
• CSS with the rules that cannot be printed in an @imported child: the failure belongs to the chunk entry, and an edit of the child alone queues the chunk again and recovers.
• CSS failure plus a change of the @import list in one batch, with a connected client: a failed chunk entry keeps its CssRoot content, so a trace keeps the place of the stylesheet and does not recurse into css children. The recovery bundle restyles the page in place.
• a stylesheet that HTML links and that another linked stylesheet imports: one edit of the shared file recovers both failed chunks.
• two @imports that cannot be printed in one chunk: both are reported.
• a failure that is broken and fixed over hot updates only, then a new stylesheet import: the css list of the route is traced again and the new link reaches the page.
• a stylesheet imported through a js file that fails to parse: the css list trace continues through failed js files, so the stylesheet stays active while the file is broken and after recovery.
• a css parse error plus an edge adjustment in one batch: insert_failure keeps a prior CssRoot through any kind of failure.
• the same with a css resolution error: insert_stale, which runs before insert_failure on that path, keeps the CssRoot the same way.

Without the fix, ten of the eleven fail on a debug build of main and ten fail on the 1.4.2 release. stylesheets imported through a failed js file stay active passes on both: it guards the trace_imports change of this PR. css resolution error with an edge adjustment failed only through the debug assert before 9993ca1. All eleven pass with the fix.

Suites

• Debug build of this branch (9993ca1), all pass: test/bake/dev/{bundle,css,html,hot,esm,plugins,incremental-graph-edge-deletion}.test.ts, test/bake/{dev-and-prod,deinitialization}.test.ts, test/js/bun/http/bun-serve-html.test.ts.
• Release build of this branch (c39a8ca), all pass: test/js/bun/http/bun-serve-html.test.ts, test/bake/dev/{bundle,css,html}.test.ts.
• The new test in bun-serve-html.test.ts fails on a release build without the fix ("stylesheets":[] during the rebuild, main 367d939 and 1.4.2) and on a debug build of main (exit 134 with the panic).

---

[human-review] gate passed · iteration 1 · 4 files touched

fails on main (without fix)

ASAN without fix: 11 failed, 2 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/bake/dev/bundle.test.ts test/js/bun/http/bun-serve-html.test.ts
bun test v1.4.3 (367d939d9)

test/bake/dev/bundle.test.ts:
Dev server testing directory: /tmp/bun-dev-test-c53kLF
^[[0;30mdev|^[[0m Started development server: http://localhost:37877
^[[0;30mdev|^[[0m ^[[32mBundled page in 136ms^[[0m^[[2m:^[[0m routes/index.ts ^[[2m+ 1 more^[[0m
^[[0;30mdev|^[[0m [Bun] Hot update was not accepted because it or its importers do not call `import.meta.hot.accept`. To prevent full page reloads, call `import.meta.hot.accept` in one of the following files to handle the update:
^[[0;30mdev|^[[0m 
^[[0;30mdev|^[[0m Module "db.ts" is not accepted by routes/index.ts,
^[[0;30mdev|^[[0m ^[[32mReloaded in 36ms^[[0m^[[2m:^[[0m db.ts
^[[0;30mdev|^[[0m [Bun] Hot update was not accepted because it or its importers do not call `import.meta.hot.accept`. To prevent full page reloads, call `import.meta.hot.accept` in one of the following files to handle the update:
^[[0;30mdev|^[[0m 
^[[0;30mdev|^[[0m Module "routes/index.ts" is a root module that does not self-accept.
^[[0;30mdev|^[[0
... (truncated)

release without fix: all passed
bun test v1.4.3-canary.1 (88053e2b0)

test/bake/dev/bundle.test.ts:
Dev server testing directory: /tmp/bun-dev-test-P8LRSr
^[[0;30mdev|^[[0m Started development server: http://localhost:45023
^[[0;30mdev|^[[0m ^[[32mBundled page in 3ms^[[0m^[[2m:^[[0m routes/index.ts ^[[2m+ 1 more^[[0m
^[[0;30mdev|^[[0m [Bun] Hot update was not accepted because it or its importers do not call `import.meta.hot.accept`. To prevent full page reloads, call `import.meta.hot.accept` in one of the following files to handle the update:
^[[0;30mdev|^[[0m 
^[[0;30mdev|^[[0m Module "db.ts" is not accepted by routes/index.ts,
^[[0;30mdev|^[[0m ^[[32mReloaded in 1ms^[[0m^[[2m:^[[0m db.ts
^[[0;30mdev|^[[0m [Bun] Hot update was not accepted because it or its importers do not call `import.meta.hot.accept`. To prevent full page reloads, call `import.meta.hot.accept` in one of the following files to handle the update:
^[[0;30mdev|^[[0m 
^[[0;30mdev|^[[0m Module "routes/index.ts" is a root module that does not self-accept.
^[[0;30mdev|^[[0m ^[[36m[x2]^[[0m ^[[32mReloaded in 1ms^[[0m^[[2m:^[[0m routes/index.ts
(pass)  DEV:bundle-1: import identifier doesnt get renamed [203.24ms]
^[[0;30mdev|^[[0m Started development server: http://localhos
... (truncated)

passes on PR (with fix)

ASAN with fix: 2 skipped
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/bake/dev/bundle.test.ts test/js/bun/http/bun-serve-html.test.ts
bun test v1.4.3 (367d939d9)

test/bake/dev/bundle.test.ts:
Dev server testing directory: /tmp/bun-dev-test-iBB0eM
^[[0;30mdev|^[[0m Started development server: http://localhost:43439
^[[0;30mdev|^[[0m ^[[32mBundled page in 155ms^[[0m^[[2m:^[[0m routes/index.ts ^[[2m+ 1 more^[[0m
^[[0;30mdev|^[[0m [Bun] Hot update was not accepted because it or its importers do not call `import.meta.hot.accept`. To prevent full page reloads, call `import.meta.hot.accept` in one of the following files to handle the update:
^[[0;30mdev|^[[0m 
^[[0;30mdev|^[[0m Module "db.ts" is not accepted by routes/index.ts,
^[[0;30mdev|^[[0m ^[[32mReloaded in 38ms^[[0m^[[2m:^[[0m db.ts
^[[0;30mdev|^[[0m [Bun] Hot update was not accepted because it or its importers do not call `import.meta.hot.accept`. To prevent full page reloads, call `import.meta.hot.accept` in one of the following files to handle the update:
^[[0;30mdev|^[[0m 
^[[0;30mdev|^[[0m Module "routes/index.ts" is a root module that does not self-accept.
^[[0;30mdev|^[[0
... (truncated)

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped) in 736ms (unchanged)
ninja: Entering directory `/workspace/bun/build/release'
[1/7] gen generated_host_exports.rs
generated_host_exports.rs: 121 exports (host=5, lazy=10, generic=106, rust=0); 245 extern-C blocks audited
[1/7] cargo bun_runtime → libbun_runtime.a
^[[1m^[[33mwarning^[[0m^[[1m: binary `bun_shim_impl` should have a kebab-case name^[[0m
   ^[[1m^[[94m|^[[0m
^[[1m^[[94m 1^[[0m ^[[1m^[[94m|^[[0m /workspace/bun/build/release/rust-target/.../bun_shim_impl
   ^[[1m^[[94m|^[[0m                                              ^[[1m^[[33m^^^^^^^^^^^^^^[[0m
   ^[[1m^[[94m|^[[0m
   ^[[1m^[[94m= ^[[0m^[[1mnote^[[0m: `cargo::non_kebab_case_bins` is set to `warn` by default
^[[1m^[[96mhelp^[[0m: to change the binary name to `bun-shim-impl`, convert `bin.name`
  ^[[1m^[[94m--> ^[[0msrc/install/windows-shim/Cargo.toml:41:8
   ^[[1m^[[94m|^[[0m
^[[1m^[[94m41^[[0m ^[[91m- ^[[0mname = ^[[91m"bun_shim_impl"^[[0m
^[[1m^[[94m41^[[0m ^[[92m+ ^[[0mname = ^[[92m"bun-shim-impl"^[[0m
   ^[[1m^[[94m|^[[0m
^[[1m^[[33mwarning^[[0m: `bun_shim_impl` (manifest) generated 1 warning
^[[1m^[[33mwarning^[[0m^[[1m: `feature(generic_const_exprs)` is not supported with
... (truncated)

diff hotspot

src/runtime/bake/DevServer.rs                    | 131 +++++++-
 src/runtime/bake/dev_server/incremental_graph.rs | 144 +++++++--
 test/bake/dev/bundle.test.ts                     | 380 +++++++++++++++++++++++
 test/js/bun/http/bun-serve-html.test.ts          | 121 ++++++++
 4 files changed, 743 insertions(+), 33 deletions(-)

gate history · 3 passed · 0 rejected · iteration 1

evidence per changed file

file                                              reads  edits  tests
src/runtime/bake/DevServer.rs                         0      0      5
src/runtime/bake/dev_server/incremental_graph.rs      1      3      5
test/bake/dev/bundle.test.ts                          0      0      1
test/js/bun/http/bun-serve-html.test.ts               1      3      4

root cause · written by the author bot

The dev server dropped a per-file print failure of the JavaScript or CSS printer in finalize_bundle and served an empty module or an empty stylesheet with no error. The fix records each print failure as a per-file failure in the incremental graph (insert_failure), skips the failed JavaScript parts, and leaves failed CSS chunks out of the hot update payload. A failed stylesheet keeps its CssRoot content and, while a rebuild is in flight, its asset, so a page served in between still links it. invalidate is unchanged: the existing CSS root arm re-enqueues a failed stylesheet.

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

Walkthrough

Changes

Bundle finalization records JavaScript and CSS printer failures per file. Incremental graph tracing and invalidation re-enqueue failed entries for recovery. DevServer tests cover client, server, CSS imports, hot updates, and shared stylesheet recovery.

Printing failure recovery

Layer / File(s)	Summary
Record printing failures src/runtime/bake/DevServer.rs	JavaScript and CSS printing failures create graph diagnostics. Failed JavaScript parts are skipped. Failed CSS routes retain prior HMR CSS identifiers, and failed CSS chunks are omitted from HMR payloads.
Re-enqueue failed graph entries src/runtime/bake/dev_server/incremental_graph.rs	Import tracing handles failed JavaScript and CSS files. Client invalidation restores failed CSS roots, marks failed dependents stale, and re-enqueues them with the required entry-point handling.
Validate failure and recovery test/bake/dev/bundle.test.ts	Tests cover per-file errors, server responses, CSS import-edge updates, hot-update recovery, failed JavaScript CSS tracing, and recovery of shared stylesheet entries.

Suggested reviewers: jarred-sumner

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title clearly and concisely describes the primary change: reporting per-file printer failures instead of serving empty modules in the dev server.
Description check	✅ Passed	The description provides detailed problem context, implementation details, verification results, tests, and known limitations. It does not use the exact template headings, but it covers the required c…

---

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

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🔴 src/runtime/bake/DevServer.rs:4325-4338 — When the failing CSS is an @imported child (e.g. main.css imports child.css and child.css contains the unprintable rules), Pass 1 attaches the failure to main.css and Pass 2 skips the chunk, so process_css_chunk_import_records never runs and child.css never gets a CssChild entry in bundled_files. The overlay then names child.css (via err_source), but editing child.css hits invalidate()'s get_index → None → continue and no rebuild is enqueued — the user must touch main.css to clear the error. Pre-PR, Pass 2 ran on the near-empty stylesheet and registered the child, so editing it did rebuild the chunk; consider registering the chunk's import-record children (or caching the entry index so Pass 2 can run) in the failure branch.

  Extended reasoning...

  What the bug is

  When a CSS chunk fails to print because of a non-entry @imported file, the PR's new failure path leaves that child file unregistered in the incremental graph. The error overlay names the child file, but editing it does not trigger a rebuild — the overlay stays up until the user edits the entry CSS file instead. This is a regression: before this PR, editing the child file did trigger a rebuild.

  Code path

  Take index.html → <link href="main.css">, with main.css containing @import "./child.css"; and child.css containing the 30 nested :fullscreen rules from the PR's own repro.

  Pass 1 (DevServer.rs:4097-4133): the chunk's compile results contain an Err for child.css. The new find_map picks it up with err_source_index = child.css, so err_source = child.css and the log message reads child.css: error: Failed to generate CSS for this file (PrintError). insert_failure is called with entry_source.path = main.css and then continue skips receive_chunk.

  insert_failure (incremental_graph.rs:1417-1455) only touches bundled_files[main.css]: it pushes first_dep/first_import = None for a new entry and sets kind = FileKind::Unknown. It never walks import records, so child.css is not inserted.

  Pass 2 (DevServer.rs:4325-4338): the chunk contains an Err result, so it continues. process_chunk_dependencies(..., ProcessMode::Css, entry_index) never runs, so process_css_chunk_import_records never reaches the mode == Css branch at incremental_graph.rs:991-994 that would call self.insert_empty(child.css, FileKind::Css) and create the main.css → child.css edge.

  Hot reload: the user sees the overlay naming child.css, fixes it, and saves. HotReloadEvent::process_file_list calls client_graph.invalidate([child.css], &mut entry_points). At incremental_graph.rs:1577:

  let Some(index) = self.bundled_files.get_index(path) else {
      continue;
  };

  child.css is not in bundled_files → continue. entry_points stays empty → "nothing to bundle" → no rebuild is enqueued. The error overlay persists.

  Why existing code doesn't prevent it

  The Pass-2 skip is required — Pass 1 no longer calls receive_chunk, so ctx never caches the entry's file index and process_chunk_dependencies would hit .expect("unresolved index"). But the skip drops the side effect of registering @imported children. insert_failure was designed for parse failures where import records don't exist; here they do (parsing succeeded, only printing failed), but nothing consumes them.

  Why this is a regression

  Pre-PR, Pass 1 called receive_chunk(main.css, Css(hash)) with the near-empty /* child.css */ stylesheet, which cached the entry index. Pass 2 then ran process_css_chunk_import_records, which walked import_records[main.css] (populated at parse time, unaffected by the print failure), hit the mode == Css branch at line 992, and called insert_empty(child.css, FileKind::Css) — creating the CssChild entry and the main.css → child.css edge. Editing child.css then matched Content::CssChild at incremental_graph.rs:1589, walked first_dep to main.css (CssRoot), and enqueued it via append_css at line 1608. The chunk rebuilt and the fixed stylesheet was served.

  Impact

  The PR's stated recovery contract — "stale bit so the file rebuilds once edited" — does not hold for the file the error message actually names when that file is @imported rather than directly linked. The user is told exactly which file to fix, fixes it, and nothing happens. @import from an entry stylesheet into shared CSS is a common pattern. The PR's CSS test only covers the case where the entry file itself is the failing file (amp.css linked directly from HTML), so this variant is untested.

  Step-by-step proof

  1. main.css: @import "./child.css"; body { margin: 0; }
  2. child.css: 30 nested .xN:fullscreen { … } rules (the PR's repro).
  3. Initial bundle: chunk entry = main.css, compile results = [Ok(main), Err(PrintError, source_index=child)].
  4. Pass 1: find_map → (PrintError, child); log attributes to child.css; insert_failure(main.css); continue. bundled_files = { main.css: Unknown/failed }. No child.css.
  5. Pass 2: chunk has an Err → continue. No process_chunk_dependencies.
  6. Overlay shows child.css: error: Failed to generate CSS for this file (PrintError).
  7. User rewrites child.css to .visible { color: blue; }.
  8. invalidate([child.css]) → get_index(child.css) = None → continue. entry_points empty. No rebuild.
  9. Overlay unchanged. User must additionally touch main.css (which is in bundled_files, routes through the _ => append_js fallback since its content is Unknown, and enqueues a rebuild) to recover.

  Fix

  In the Pass-1 CSS failure branch, after insert_failure on the entry, also register each @imported CSS source from chunk.compile_results_for_chunk / the chunk's import records via client_graph.insert_empty(child_path, FileKind::Css) and attach the entry → child edge (mirroring what process_css_chunk_import_records does). Alternatively, have insert_failure cache the entry's file index in ctx so Pass 2 can run process_chunk_dependencies for failed chunks too. Either way, add a test variant where the failing CSS is @imported and recovery edits the child file.

[robobun]

Good catch on the @imported child case: the failure sat on the chunk entry while the child never entered the graph, so editing the child hit the get_index -> None -> continue path in invalidate and no rebuild was enqueued.

Fixed in 99c3514 with the second suggested approach plus one more piece it needed:

• the failure branch now caches the entry's file index so pass 2 runs process_chunk_dependencies for failed CSS chunks too, registering the @import children and their edges (the pass-2 skip for CSS is gone)
• invalidate's CssChild walk re-enqueues dependents whose last build failed (their content is Unknown, not CssRoot, so the edge alone was not enough; they now route through append_js the way a direct edit of a failed file does)

Added the suggested test variant: the unprintable rules live in @import"./child.css" and recovery edits only the child. It times out on the previous commit and passes now.

[robobun]

Applied the suggested mirror in a264758: the failure branch now calls insert_css_file_on_server when metadata.imported_on_server, so the server graph keeps its stub and cached index for edge attachment.

One honest caveat on reachability: I could not construct a server-imported CSS chunk that actually fails to print today. Both printer-guard repros (30 nested :fullscreen rules tripping the vendor-prefix expansion budget, and 40 nested two-selector lists tripping selector expansion) error when the stylesheet is linked from an HTML route, but the identical files print cleanly when imported from a framework route, no prefix fan-out at all. The target-dependent prefix data appears not to be assigned for CSS parsed via a server-graph import, which is its own inconsistency (dev serves unprefixed CSS for server-imported stylesheets) and I am tracking it separately. So this commit has no test; it keeps the failure branch consistent with the success path for whenever that pipeline can fail.

[claude]

Additional findings (outside current diff — PR may have been updated during review):

• 🟡 src/runtime/bake/dev_server/incremental_graph.rs:1609-1616 — When a stylesheet is both a chunk entry (linked from HTML) and @imported by another linked stylesheet, a print failure in it makes Pass 1 call insert_failure on both chunk entries, so both get content = Content::Unknown. Fixing the file then routes invalidate through the Js(_) | Unknown arm — which enqueues only the edited file and never walks first_dep — so the importing root is not re-enqueued and stays failed with a stale error until the user touches it. This new branch handles the mirror direction (edited CssChild → failed dependent) but not edited failed-root → failed dependent; same underlying gap as the open trace_imports/CssChild finding, and preserving CSS kind through insert_failure (or walking first_dep from the Unknown arm when failed) would fix both.

  Extended reasoning...

  What breaks

  Commit 99c3514 added this else if failed branch so that editing a CssChild re-enqueues a failed dependent chunk entry (whose content is now Unknown, not CssRoot). But the branch lives inside the Content::CssRoot(_) | Content::CssChild match arm of invalidate, so it only fires when the edited file is still tagged as CSS. When the edited file is itself a failed chunk entry (Content::Unknown), invalidate falls into the Content::Js(_) | Content::Unknown arm at the bottom, which does not iterate first_dep[index]. Any failed dependent that @imports the edited file is never re-enqueued.

  Repro topology

  index.html links both main.css and sub.css; main.css contains @import "./sub.css";; sub.css has the 30-nested :fullscreen rules that trip the CSS printer's expansion guard.

  Step-by-step proof

  1. Initial bundle — both entries become Unknown. Two CSS chunks are emitted (one per <link>). sub.css's CompileResult::Css { result: Err(_) } appears in both chunks' compile_results_for_chunk (main.css bundles it via @import). Pass 1's new failure branch (DevServer.rs:4097-4139) fires for each chunk → client_graph.insert_failure(main.css) and client_graph.insert_failure(sub.css). insert_failure on the client side unconditionally sets kind = FileKind::Unknown, content = Content::Unknown, failed = true. Each chunk's failure branch also sets ctx.get_cached_index(Client, entry_src_idx).

  2. Pass 2 creates the edge; sub.css stays Unknown. Pass 1 completes over all CSS chunks before Pass 2's CSS loop runs, so both cached indices are set. process_chunk_dependencies(Css) for main.css walks its @import record for sub.css; process_edge_attachment finds ctx.get_cached_index(Client, sub_css_idx) is Some (set in step 1 by sub.css's own chunk) and breaks with that index — it does not reach the insert_empty(FileKind::Css) fallback, so sub.css is never overwritten to CssChild. The edge is created: first_dep[sub.css] now includes main.css.

  3. User fixes sub.css → wrong invalidate arm. client_graph.invalidate([sub.css]) matches on sub.css.content == Content::Unknown → the Content::Js(_) | Content::Unknown arm → entry_points.append_js(sub.css, Client) only. The CssRoot | CssChild arm's first_dep walk (which would find main.css and hit this new else if failed branch) never runs.

  4. Rebuild clears only sub.css. Only the sub.css chunk is enqueued; receive_chunk(sub.css) clears its failure. main.css remains { failed: true, content: Unknown }; its bundling_failures entry (whose message points at sub.css) persists. trace_imports(FindErrors) from index.html still reaches it, so the route keeps serving the error page for a file the user has already fixed. Recovery requires touching main.css.

  Why this is a regression

  Before this PR, a print-failed CSS chunk still ran receive_chunk (with the header-only asset), so both entries kept content = CssRoot(_). Editing sub.css matched the CssRoot | CssChild arm, walked first_dep[sub.css] → found main.css (CssRoot) → append_css(main.css). Both roots re-bundled and recovered in one edit.

  Impact and fix

  This is the same root cause as the open trace_imports/CssChild debug_assert finding: insert_failure on a CSS entry erases the CSS marker so downstream code that keys on Content::CssRoot | CssChild skips it. 99c3514 patched one direction (edited CssChild → failed dependent) but not this one (edited failed-Unknown root → failed dependent). Either (a) the Js | Unknown arm in invalidate should walk first_dep when failed is true and re-enqueue CssRoot/failed dependents, or (b) insert_failure for a client-side CSS entry should preserve enough kind/content state to keep routing through the CSS arm — which would also address the open trace_imports finding.

  Filing as a nit given the narrow trigger (a stylesheet must be both directly <link>'d and @imported by another <link>'d stylesheet, and hit a printer failure) and trivial workaround (touch main.css); the PR is still a net improvement over the silent empty stylesheet.

[robobun]

Confirmed the both-linked-and-imported case: fixing the shared stylesheet left the other failed root stuck with a stale error until it was touched. Fixed in 8526d56: invalidate's Unknown arm now walks the edited failed file's dependents and re-enqueues css roots and failed entries, the mirror of the CssChild-to-failed-dependent walk. Test added (index.html links main.css and sub.css, main.css imports sub.css, one edit of sub.css recovers both chunks); it times out on the previous commit.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/runtime/bake/DevServer.rs`:
- Around line 4094-4139: Update the failed-CSS handling around insert_failure
and the hot-update payload generation so chunks with a CSS print failure are
excluded from serialized CSS output rather than emitted as empty stylesheets.
Preserve the existing failure reporting, cached index, and server-graph
behavior, and add a regression test covering successful style → print failure →
recovery that verifies the previously active style remains until recovery.
- Around line 4630-4637: Move or add the SAFETY comment immediately before the
unsafe expression in the had_adjusted_edges condition within the surrounding
route bundle logic. Ensure it directly explains why dereferencing route_bundle
to read server_state is safe, satisfying Clippy’s unsafe-block documentation
requirement.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 61d69569-00e5-428a-af6d-ced319aa375f

📥 Commits

Reviewing files that changed from the base of the PR and between a32adeb and 8526d56.

📒 Files selected for processing (3)

• src/runtime/bake/DevServer.rs
• src/runtime/bake/dev_server/incremental_graph.rs
• test/bake/dev/bundle.test.ts

[robobun]

^{Updated 2:11 PM PT - Sep 19th, 2026}

❌ @robobun, your commit 9993ca1 has 1 failures in Build #118457 (All Failures):

• test/js/bun/spawn/spawn.test.ts - code 1: stdout reader of an unref'd child and process lifetime > an idle reader stopped at the highwater … on 🐧 13 x64-asan

---

🧪   To try this PR locally:

bunx bun-pr 37039

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

bun-37039 --bun

[robobun]

CI status for build 89633: every lane passes except debian 13 x64-asan, which fails on test/js/node/worker_threads/worker-transfer-terminate-stress.test.ts (SIGABRT). That failure is pre-existing on main and unrelated to this change; it is being tracked separately. All bake dev-server suites, including the ten tests this PR adds, pass on every lane.

[claude]

No new issues found on this pass, but this touches the bake dev server's incremental-graph state machine (failure insertion, trace_imports refactor, CssRoot preservation across insert_stale/insert_failure, invalidate re-enqueue) and went through four review rounds that each surfaced a real regression — worth a human look before merging.

What was reviewed:

• CssRoot preservation now runs free_file_content(UnrefCss) twice on the resolution-failure path (insert_stale then insert_failure); verified unref_by_path is idempotent via path_map.fetch_swap_remove, so no refcount imbalance.
• restore_failed_css_root after insert_failure on the print-failure path is redundant when the entry already existed but still needed for first-failure entries — harmless.
• The refactored trace_imports failed-file gating (css root stops, css child stops, js falls through) matches the edge invariants; the four earlier regressions each have a dedicated test.

Extended reasoning...

Overview

The PR routes JS/CSS printer failures in finalize_bundle through the existing per-file failure machinery instead of registering empty modules/stylesheets. It touches src/runtime/bake/DevServer.rs (~110 new lines in finalize_bundle pass 1/2 and the hot-update CSS payload filter) and src/runtime/bake/dev_server/incremental_graph.rs (~110 lines: refactored client-side trace_imports, new restore_failed_css_root, CssRoot preservation in insert_stale_extra and insert_failure, and failed-dependent re-enqueue in invalidate). Eleven new devTests in test/bake/dev/bundle.test.ts cover initial-load failure, hot-update failure, recovery, edge-adjustment-while-failed, and the parse/resolution/print failure siblings.

Security risks

None. The change is entirely inside the dev server's bundle-finalization and graph bookkeeping; no new inputs are parsed, no auth/crypto/filesystem surface is touched.

Level of scrutiny

High. The incremental graph is a multi-phase state machine where content/failed/kind, the parallel first_import/first_dep edge lists, and the asset refcount must stay coherent across insert_stale → insert_failure → receive_chunk → trace_imports transitions. The PR history bears this out: four prior review passes on this PR each found a concrete regression (sticky server_state guard, failed-JS early-return dropping CSS roots, parse-failure not preserving CssRoot, resolution-failure via insert_stale not preserving CssRoot), each fixed with a dedicated test. That iteration count alone argues for a human reading of the final shape.

Other factors

• Every prior inline finding (mine, CodeRabbit's, comment-cop's) is marked resolved with a fix commit and a regression test.
• CI is green except a pre-existing unrelated ASAN flake per robobun's build summary.
• I spot-checked the one new interaction the last commit introduces: insert_stale and insert_failure now both call free_file_content(UnrefCss) on a preserved CssRoot in the resolution-failure sequence. assets.unref_by_path swap-removes the path_map entry on the first call, so the second is a no-op — no double-decrement. The redundant restore_failed_css_root after insert_failure on the print path overwrites CssRoot(id) with the same path-hash id, also harmless.
• The else if failed re-enqueue branch in invalidate's Css arm may overlap with the later CssRoot-preservation commits (a failed root now matches the CssRoot(_) arm directly), but appending it for rebuild is correct either way — not a bug, just possible redundancy a maintainer may want to look at.

[robobun]

Status

This branch is merged with main (ca41503) and builds again. The build error was error[E0609]: no field first_dep on type &mut IncrementalGraph<SIDE>. Commit 48efa9f fixes it.

I ran the branch against the page request during a rebuild that the notes of #42733 describe. An onResolve plugin parks a rebuild after @import "./missing.css" failed in a linked stylesheet that already imports another one. Then the script requests the page and the stylesheet that the page links.

build	page during the rebuild
main, release canary (367d939)	200, no <link>
main, debug build	exit 134, panic: only CSS roots should be found by tracing
this branch, debug build	200, one <link>, the stylesheet answers 200 with the last good rules
this branch, release build	200, one <link>, the stylesheet answers 200 with the last good rules

test/js/bun/http/bun-serve-html.test.ts has these steps as a test (93f5382, extended in eb59386). A framework route (meta.styles) gives the same results in a probe.

Commit 9993ca1 is the result of a self-review. It removes the two walks in invalidate and the extra branches in trace_imports, which the kept CssRoot content made redundant, and it makes one test stricter. The Notes in the PR body list every concern.

Not covered: a linked stylesheet that fails to parse while another file holds the same rebuild open. insert_failure drops its asset before the rebuild ends, so its <link> answers 404 in that window. The Notes in the PR body have the probe.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

[robobun]

Addressed the optional note on the stylesheet link served during a rebuild. In eb59386, insert_stale no longer unrefs the asset of a css root it keeps routable. The asset lives until the rebuild replaces it (replace_path) or drops it (insert_failure), so the page's link serves the previous stylesheet instead of a 404. The in-flight rebuild test in bun-serve-html.test.ts now fetches every linked stylesheet and checks its status and rules. It fails on the previous commit (404 during the rebuild) and passes now. The bake dev suites (bundle, css, html) pass as well.

[robobun]

CI status for build 118107: the diff is green on every lane. The one red test is test/bake/deinitialization.test.ts on alpine aarch64, a GC check that one JS Server wrapper was not collected in afterAll. That fixture bundles a plain index.html and never reaches the failure paths this PR changes. It passed on retry on the same lane in build 118105 and on Windows in this build. The other failures passed on retry. The bake dev suites and the tests this PR adds pass on every lane. This is ready for a maintainer review.

[claude]

Code review found no issues

No high-confidence issues detected in this change.

This review covers commit 88053e2, which is no longer the latest commit on this pull request; later commits are not covered by it.

[claude]

Nothing blocking. The comments below are optional suggestions. There is no need to push a fix for them before merging.

Beyond the inline finding, I also checked that dropping the invalidate additions in 9993ca1 does not break recovery when only an @ imported child of a print-failed stylesheet is edited: the failed entry now keeps Content::CssRoot, so the existing Css arm of invalidate re-enqueues it through append_css, and the "recovery by editing the child" test in test/bake/dev/bundle.test.ts still exercises that path. The PR description's line about invalidate queuing failed dependents describes code that is no longer in the diff.

Extended reasoning...

The hunt was cut off at its bug cap rather than running dry, and one confirmed finding on check_route_failures/trace_imports is posted inline, so approval is off the table. Since the last review (88053e2), commit 9993ca1 reverted the client-side trace_imports failed-file early return for non-FindErrors goals and removed both invalidate branches that re-enqueued failed dependents; I traced the child-edit recovery path through the current invalidate Css arm (dependent with Content::CssRoot gets append_css) and confirmed the preserved CssRoot content in insert_failure/insert_stale/restore_failed_css_root is what makes that arm fire, so the simplification is behavior-preserving for the tested scenario. The only other candidate examined (the "used to" comment at test/bake/dev/bundle.test.ts:1052) is regression context, not a stale description of current state, so it was dropped as a nit.

Additional findings (outside the current diff — GitHub can't attach inline comments there):

• 🟣 src/runtime/bake/dev_server/incremental_graph.rs — Pre-existing: a developer whose linked stylesheet @ imports a child that fails to parse or resolve gets the page served 200 with the child's rules silently missing once they reload. check_route_failures runs trace_imports with FindErrors, and at incremental_graph.rs:1258 a CssRoot returns before its imports are walked, so a failed CssChild is never reported and the route is promoted to Loaded. Fix: let FindErrors reach failures below a css root, e.g. recurse into first_import under FindErrors and report a failed CssChild instead of asserting, or attach a child's parse/resolution failure to its chunk entry as the new print path does.

  Extended reasoning...

  Fixture: index.html links main.css; main.css is @ import "./child.css"; body { margin: 0 }; child.css is body {\n color: red;\n background-color\n} (the CSS parse error the PR's own test uses) or @ import "./missing.css".
  child.css fails in ParseTask; bundle_v2.rs:7609 calls handle_parse_task_failure(Client, child.css), DevServer.rs:5127 calls client_graph.insert_failure(child): failed=true, content Unknown.
  main.css still has parts, so it stays a css entry point; scan_css_imports (LinkerContext.rs:3396) raises no error for a Loader::Css record whose ast is None; findImportedFilesInCSSOrder.rs:141 skips the child; the chunk prints main's rules only and receive_chunk(main) stores CssRoot(id) with failed=false.
  Pass 2 process_css_chunk_import_records inserts the edge main -> child via insert_empty (found existing).
  index_failures traces child -> main -> index.html and sets the route to PossibleBundlingFailures (DevServer.rs:3409); the overlay shows the error on the open page.
  The user reloads. DevServer.rs:2050 calls check_route_failures;…

  Verification: pre-existing. Triggering condition: a CSS root linked by an HTML route (or imported by a script) @ imports a child stylesheet that fails to parse (or to resolve), and the developer reloads the page after the first error response. Mechanism verified in the head checkout: - Child parse failure: bundle_v2.rs:7609 / DevServer.rs:5127 -> client_graph.insert_failure(AbsPath(child.css)) sets…

[robobun]

Updated the root cause paragraph of the PR body. It no longer says that invalidate queues failed dependents. 9993ca1 removed those walks, and the existing CSS root arm re-enqueues a failed stylesheet because it keeps its CssRoot content.

The other note is a gap of main, not of this PR: a child stylesheet that fails to parse under a root that prints is not found by the FindErrors trace on reload, because trace_imports stops at a CssRoot before it walks the imports. The code of main does the same. This PR does not change that walk, so I leave it for a change of its own.

[Jarred-Sumner]

This is Claude (an AI assistant) commenting on Jarred's behalf.

This fix went in with #46021, which is merged. Closing.