bake: name both flags at every insert_stale_extra call

[robobun]

Problem

• IncrementalGraph::insert_stale_extra (src/runtime/bake/dev_server/incremental_graph.rs:1286) takes two bools, is_ssr_graph and is_route, and three of its four calls pass them as bare literals: insert_stale_extra(path, false, true) at DevServer.rs:952, :5229 and :5850. Nothing at those sites says which flag is which, and the swapped call compiles.
• mordant reports it as bare_bool_args (the bare_bool_args:src/runtime/bake/dev_server/incremental_graph.rs entry in mordant-baseline.toml).

Fix

• The graph flag becomes a bake::Graph. Every caller already holds one: the client graph passes Graph::Client, the server graph passes Graph::Server (the RSC graph) or Graph::Ssr, and get_log_for_resolution_failures passes its graph straight through instead of graph == bake::Graph::Ssr. Inside, the server arm derives is_ssr_graph from it, so the body is otherwise unchanged. A debug_assert! checks the graph passed matches the side of the graph it is inserted into, since a three-variant enum could otherwise be handed to the wrong side.
• The route flag becomes a two-variant incremental_graph::RouteKind { NotRoute, Route } (same shape as BakeRouteKind in src/bundler/OutputFile.rs). Its one-line doc records the contract the bool left implicit: a Route inserted on the server must also be registered in DevServer::route_lookup, because trace_dependencies panics on a route it cannot find there. Both server callers already do this right after the insert.
• insert_stale stays a forwarder and now passes RouteKind::NotRoute; its four callers take the bake::Graph change.
• No behavior change: every call passes the same values as before. That includes the client HTML route at DevServer.rs:5229, which still passes Route even though the client graph ignores the flag (it always has; HTML routes are found through html_route_bundle_index). Dropping it there would have been a judgment call outside this change.
• mordant-baseline.toml is regenerated with bun run rust:mordant:baseline; against current main the only difference is this finding's entry. (The first revision also dropped two entries for findings fixed on main after ci: bump the mordant pin (sixteen new lints) and record their baseline #38846 recorded the counts; main has since removed those itself, and merging main in folded that away.)
• No new test under test/: nothing observable changed, so a JS-level test would pass with and without this diff. The regression guard is the removed baseline entry itself: with it gone, the mordant job fails on any future call that passes bare bools here again (the control run below is that failure, produced on purpose).
• Verified:
  • bun bd test on test/bake/dev/{html,esm,bundle,incremental-graph-edge-deletion,react-response,react-spa,ssg-pages-router,server-sourcemap}.test.ts: 80 pass, 0 fail. These cover every changed call site (framework router setup and get_file_id_for_router, react refresh, HTML route bundles, resolution failures on both graphs, and the route hot-reload path that relies on is_route).
  • After merging main (which brought in dev server: keep a file's two edge list heads in one Vec #39151's changes to the same file), html, bundle and incremental-graph-edge-deletion re-run on the debug build: 32 pass, 0 fail.
  • bun run rust:mordant on this branch: no warnings, no target/mordant/over-baseline.txt.
  • Control: the same run with the two source files reverted (baseline entry still removed) reports exactly the finding above, bun_runtime 1 over baseline.
  • cargo clippy -p bun_runtime --no-deps: clean.

Background

• The dev server keeps two IncrementalGraphs, one per bake::Side (client and server). The server graph holds files for two bundler graphs at once: Graph::Server, the RSC graph where routes and server components live, and Graph::Ssr, the copies of client components bundled for rendering on the server. A server File records which of the two it belongs to in is_rsc / is_ssr; a file can be in both.
• "Stale" insertion registers a path in the graph without bundled content so it can be traced and queued for bundling; routes, framework entry points and files that failed to resolve all enter this way.
• route_lookup maps a server file index to the framework route it belongs to. trace_dependencies uses File::is_route to decide whether to consult it when a change propagates to that file, which is why the Route flag carries a registration obligation.
• mordant is the advisory lint pack run by the rust-lints workflow; mordant-baseline.toml holds per-(lint, file) counts of pre-existing findings, and a PR fails the job only if it adds one. Removing a fixed finding's entry keeps it from coming back.

[robobun]

^{Updated 2:05 PM PT - Aug 15th, 2026}

@robobun, your commit ff1ceeb is building: #98634

[robobun]

Status: ready for review.

• Requested in Slack by @alii as the fix for the bare_bool_args finding on insert_stale_extra.
• Verified locally: 80 bake dev tests pass on the debug build (32 re-run after merging main); bun run rust:mordant is clean on this branch and reports exactly this finding with the source change reverted. Against current main the baseline diff is the one entry.
• On ff1ceeb: the mordant CI job is green with the entry removed, as are clippy, format and comment-cop; review threads are all resolved. miri and the buildkite build are still running. (The earlier build 98445 on c0f0e50 had 177 of 179 jobs green, the other two being darwin 14 aarch64 lanes that never started before it was canceled.)

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 07aa8823-5aeb-4470-b1d2-2a0bedbf4e82

📥 Commits

Reviewing files that changed from the base of the PR and between bcab5ed and c0f0e50.

📒 Files selected for processing (3)

• mordant-baseline.toml
• src/runtime/bake/DevServer.rs
• src/runtime/bake/dev_server/incremental_graph.rs

💤 Files with no reviewable changes (1)

• mordant-baseline.toml

---

Walkthrough

Changes

The incremental graph API now accepts explicit bake::Graph and RouteKind values. DevServer call sites use these values for stale files, routes, resolution failures, HTML routes, and router files. Three Mordant configuration entries were removed.

Bake graph routing

Layer / File(s)	Summary
Incremental graph insertion contract src/runtime/bake/dev_server/incremental_graph.rs	Adds RouteKind and updates stale insertion to derive SSR state from bake::Graph.
DevServer call-site migration src/runtime/bake/DevServer.rs, mordant-baseline.toml	Passes explicit graph and route-kind values across DevServer insertion paths and removes three configuration entries.

Possibly related PRs

• oven-sh/bun#32078: Introduces the bake::Graph-based APIs used by this refactor.
• oven-sh/bun#37850: Changes related DevServer and incremental-graph route failure bookkeeping.

Suggested reviewers: jarred-sumner, alii, dylan-conway

🚥 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 identifies the main change: replacing positional boolean arguments with named values at insert_stale_extra call sites.
Description check	✅ Passed	The description explains the problem, fix, behavior preservation, background, and verification results in detail.

---

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

[claude]

LGTM — mechanical refactor replacing two bare bool params with typed enums; every call site maps to the same value as before.

What was reviewed:

• Traced all 8 insert_stale/insert_stale_extra call sites: each new bake::Graph/RouteKind argument produces the identical is_ssr_graph/is_route value the old bool did.
• get_log_for_resolution_failures server branch: graph == Ssr derivation moved into the callee, semantically unchanged.
• bake::Graph has exactly {Client, Server, Ssr}; the new debug_assert! correctly guards against passing the wrong side's variant.
• mordant-baseline.toml: the two extra dropped entries are already-fixed-on-main findings (#38271, #37648), consistent with a full rust:mordant:baseline regen.

Extended reasoning...

Overview

This PR replaces two bare bool parameters on IncrementalGraph::insert_stale_extra (is_ssr_graph, is_route) with typed values: the existing three-variant bake::Graph enum and a new two-variant RouteKind enum. The forwarder insert_stale is updated in step, and all 8 call sites in DevServer.rs are converted. mordant-baseline.toml is regenerated, dropping the bare_bool_args entry this fixes plus two entries already resolved on main.

Behavior preservation

I traced every changed call site against the old bool arguments:

• client_graph.insert_stale(..., false) → Graph::Client: client arm never read is_ssr_graph.
• server_graph.insert_stale_extra(..., false, true) (framework router entry, get_file_id_for_router) → (Graph::Server, RouteKind::Route): is_ssr_graph = (Graph::Server == Ssr) = false, is_route = true. Identical.
• client_graph.insert_stale_extra(..., false, true) (HTML route) → (Graph::Client, RouteKind::Route): client arm ignores both flags. Identical.
• get_log_for_resolution_failures: the server branch previously passed graph == bake::Graph::Ssr; now it passes graph and the callee computes graph == bake::Graph::Ssr in the Side::Server arm. Identical. The client branch is guarded by graph == Graph::Client, so passing graph through satisfies the new debug_assert.

The added debug_assert! matching SIDE against the passed Graph variant is a strict tightening (compiles out in release) and cannot fire on any existing call site. bake::Graph (bundle_v2.rs:362) has exactly the three variants the assert covers.

Security risks

None. This is a type-level refactor of internal dev-server graph bookkeeping with no user-facing input handling, no I/O, and no change to control flow.

Level of scrutiny

Low-to-medium. The change is mechanical and self-contained to the bake dev server. The author ran the full relevant bake test suite (80 tests across 8 files covering every changed call site), verified mordant is clean with a control run, and clippy is clean. The PR description is thorough and accurately describes what was done and why the extra baseline entries drop.

Other factors

• No prior reviews or outstanding comments on the PR.
• The two incidental mordant-baseline.toml deletions are explained with linked PRs and are the expected side effect of a full baseline regen; #39151 in flight makes the same drops.
• The new RouteKind doc comment records the previously-implicit contract that server Route insertions must be registered in route_lookup, which is a nice clarity win with no code effect.

[claude]

I reviewed this PR and found no bugs — every insert_stale/insert_stale_extra call site passes the same effective values as before (Graph::Server/Graph::Client → is_ssr_graph = false, Graph::Ssr → true; RouteKind maps 1:1 to the old bool), and the new debug_assert! holds at all seven callers. Deferring only because the two comment-cop threads on the added doc comments are still open; a maintainer should decide whether to resolve them (they document the route_lookup registration invariant, not a workaround) or trim them.

What was reviewed:

• All 4 insert_stale and 3 insert_stale_extra callers traced against the old bool values — no semantic drift.
• get_log_for_resolution_failures else-branch: graph is already != Client there, so the debug_assert holds and is_ssr_graph derivation matches the old graph == bake::Graph::Ssr.
• bake::Graph confirmed three-variant (Client/Server/Ssr); client arm never reads is_ssr_graph, so moving its computation into the server arm is safe.
• mordant-baseline.toml diff drops only the one fixed entry.

Extended reasoning...

Overview

This PR replaces two bare bool parameters on IncrementalGraph::insert_stale_extra with typed values: is_ssr_graph: bool becomes graph: bake::Graph (the existing three-variant Client/Server/Ssr enum), and is_route: bool becomes a new two-variant RouteKind enum. The forwarder insert_stale and all seven call sites in DevServer.rs are updated. A debug_assert! guards that the passed Graph matches the const-generic SIDE of the graph. The mordant baseline entry for the fixed bare_bool_args finding is removed.

Behavior preservation

I traced each caller against the old signature. The three direct insert_stale_extra calls all previously passed (false, true); they now pass (Graph::Server, Route) or (Graph::Client, Route), and since is_ssr_graph is now derived as graph == Graph::Ssr inside the server arm (and ignored on the client arm), the effective values are identical. The four insert_stale callers previously passed false (client) or graph == bake::Graph::Ssr (server resolution-failure path); passing graph through and deriving inside yields the same result. The debug_assert! holds at every call site: client callers pass Graph::Client, server callers pass Server or Ssr, and the resolution-failure else-branch is guarded by graph != Client.

Security risks

None. This is a type-level refactor of an internal dev-server graph API with no user-facing surface, no parsing of external input, and no change to control flow in release builds.

Level of scrutiny

Low-to-medium. The change is mechanical and self-contained to the bake dev server, with a well-argued PR description, passing bake test suite (80 tests), and a control run showing the mordant lint fires without the source change. The only new runtime code is a debug_assert! that compiles out in release.

Other factors / why deferring

The comment-cop bot left two unresolved inline threads on the new doc comments (the RouteKind doc and the insert_stale_extra graph parameter doc). The bot is a blunt heuristic that flags any 2+ line comment block on claude-labeled PRs and does not fail CI. The flagged comments document a real invariant — that RouteKind::Route on the server obliges the caller to register in route_lookup, which trace_dependencies otherwise panics on — so they read as legitimate API documentation rather than workaround justification. But whether to keep or trim them is a repo-style call a maintainer should make, and I don't want to approve over open review threads.

[claude]

LGTM — mechanical bool→enum refactor with no behavior change.

What was reviewed:

• Traced all six insert_stale/insert_stale_extra call sites: each passes the same effective is_ssr_graph/is_route values as before; bake::Graph has exactly {Client, Server, Ssr} so the new debug_assert and graph == Ssr derivation are exhaustive.
• Confirmed the client-side arm never reads graph or route beyond the assert, matching the old behavior of ignoring both bools on the client.
• The comment-cop notices fired on the pre-ff1ceeb0 doc; that commit trimmed RouteKind's doc to one line, so they're addressed.

Extended reasoning...

Overview

This PR replaces two positional bool parameters on IncrementalGraph::insert_stale_extra (is_ssr_graph, is_route) with typed values: the existing three-variant bake::Graph enum and a new two-variant RouteKind enum. The forwarder insert_stale and all six call sites in DevServer.rs are updated, a debug_assert guards against passing a client graph value to the server-side graph or vice versa, and the corresponding bare_bool_args entry is dropped from mordant-baseline.toml.

Behavior preservation

I traced each call site against the old arguments. Framework router entry (Graph::Server, Route ← false, true), react-refresh and framework client entry (Graph::Client ← false, ignored on client), get_log_for_resolution_failures (passes graph through; the server arm now computes is_ssr_graph = graph == Ssr, identical to the old graph == bake::Graph::Ssr at the call site), HTML route bundle (Graph::Client, Route ← false, true, both still ignored on the client arm), and get_file_id_for_router (Graph::Server, Route ← false, true). bake::Graph has exactly three variants (bundle_v2.rs:362), so the debug_assert partition and the == Ssr derivation are exhaustive. No path changes semantics.

Security risks

None. This is a type-level refactor of internal dev-server bookkeeping with no user-facing input handling, no unsafe blocks added, and no change to control flow in release builds (the only new runtime code is a debug_assert).

Level of scrutiny

Low-to-medium. The change is mechanical and self-contained to the bake dev server, follows an established pattern in this repo (several recent PRs in the git log do the same bool→enum conversion for other mordant bare_bool_args findings), and the removed baseline entry is the regression guard. The author ran the full bake dev test suite (80 tests) plus mordant/clippy, and did a control run confirming mordant re-flags with the source reverted.

Other factors

The two comment-cop bot comments (posted 19:31 UTC) predate the response commit ff1ceeb ("trim the RouteKind doc to the route_lookup obligation", built ~19:38 UTC per the updated robobun comment), which reduced the RouteKind doc to the single line now in the diff — so those are addressed. No prior review from me on this PR. No outstanding human reviewer comments.