router.commitLocation is a no-op on 1.170.36 / router-core 1.171.30, so router.navigate() silently does nothing

[NickyTope]

Which project does this relate to?

Router

Describe the bug

On @tanstack/react-router 1.170.36 with @tanstack/router-core 1.171.30, router.navigate() does nothing at all on a router created programmatically. history.location, latestLocation and state.location all stay on the previous entry, the promise resolves undefined, and state.status is back to idle — so there is no pending navigation to await.

It is not path matching or location building. router.buildLocation({ to: ".", search: (p) => ({ ...p, list: "sexes" }) }) returns the correct /operations?tab=lookup-data&list=sexes on both versions. Passing that straight to router.commitLocation({ ...built, replace: true }) moves history on 1.170.35 and does not on 1.170.36. The regression is on the commit side.

Every navigation shape I tried is affected:

probe	1.170.35	1.170.36
to: "." + functional search updater	applied	no-op
to: "." + object search	applied	no-op
to: "/operations" + functional updater	applied	no-op
no to + functional updater	applied	no-op
to: "/horses/$id" + params (path change)	applied	no-op

Caveat, stated up front: the router in this reproducer is created programmatically and never rendered through RouterProvider. I have not established whether a mounted router is affected. I am reporting it because this shape is how a lot of test suites drive the router, and because the pair of patch releases changes it.

Complete minimal reproducer

https://gist.github.com/NickyTope/bcf0b4e05e194dc3b39406cc45c6783c

Steps to Reproduce the Bug

mkdir tsr-repro && cd tsr-repro
# take package.json and repro.mjs from the gist
npm i @tanstack/react-router@1.170.36 @tanstack/router-core@1.171.30
node repro.mjs     # every probe prints NO-OP; history never moves

npm i @tanstack/react-router@1.170.35 @tanstack/router-core@1.171.29
node repro.mjs     # every probe prints "applied"

The last two lines of the script isolate it:

buildLocation  -> /operations?tab=lookup-data&list=sexes
after commit   -> /operations?tab=lookup-data        <- 1.170.36
after commit   -> /operations?tab=lookup-data&list=sexes  <- 1.170.35

Expected behavior

await router.navigate({ ... }) moves the router, as it does on 1.170.35 — history, latestLocation and state.location all reflect the new location. Equivalently, commitLocation applies a location that buildLocation built correctly.

Platform

• OS: Linux (NixOS), x86-64
• Node: 24.20.0
• @tanstack/react-router: 1.170.36 (broken) vs 1.170.35 (working)
• @tanstack/router-core: 1.171.30 (broken) vs 1.171.29 (working)
• No bundler or framework involved — plain node repro.mjs

Additional context

Found because a Renovate patch bump turned a suite red that exists specifically to catch router behaviour changes. Holding at 1.170.35 for now.

[dvd233]

Root-cause analysis, verified locally against the published packages.

The no-op comes from #8354 (perf(history): use lightweight history for server rendering). It added this guard to commitLocation (and the navigate wrappers) in packages/router-core/src/router.ts:

if (isServer ?? this.isServer) {
  return
}

this.isServer is computed as this.options.isServer ?? isServer ?? typeof document === 'undefined' (router.ts:1268), so any router running in plain Node — including the programmatic routers test suites drive — now satisfies the guard and every commit becomes a no-op. It's not version-pair specific: with the same router-core@1.171.32, react-router@1.170.35 commits and 1.170.36 no-ops (clean-room A/B). The bisect is the guard, nothing else.

I can reproduce the reporter's matrix exactly: memory history + buildLocation + commitLocation({ ...built, replace: true }) moves on 1.170.35 and never moves on ≥1.170.36, while router.isServer === true in Node.

The intent in the changeset and docs/router/guide/ssr.md is explicit ("make server navigation a no-op ... To redirect a request, use the dedicated redirect API"), so this looks like a deliberate contract for SSR render passes. The collateral is programmatic Node usage, where no SSR render pass exists. Two possible directions, depending on how you want to treat that usage:

1. Intended — then the actionable answer for test suites is router.commitLocation({ ...built, replace: true, isServer: false }) (the option exists since perf(history): use lightweight history for server rendering #8354), and it may be worth a one-line mention in the migration/docs, since patch-version suites that drive the router programmatically now silently no-op.
2. Unintended breadth — scope the guard to the SSR no-op history instead of the environment: createServerHistory already no-ops push/replace, so a marker on that history type (e.g. history.isServerHistory) would make commitLocation skip only for actual SSR request handling while keeping programmatic memory-history usage working in Node.

Happy to implement either, but I didn't want to guess which contract you want before opening a PR.

[NickyTope]

Thanks for tracking this down. You've found the right cause.

One correction, though: the workaround you suggested doesn't fix it. I tested it, and so did a few variations:

• Passing isServer: false to commitLocation does nothing. That function never reads the option.
• Passing isServer: false to createRouter does nothing in plain Node either. The package has its own built-in isServer value, which is set to true in Node, and that value is checked first. Your option never gets a look in.
• The only time that built-in value steps aside is when NODE_ENV is test. Even then, the router crashes unless you also give it an origin, because it tries to read window.origin and there's no window in Node.

So the only way to make navigation work in Node today is NODE_ENV=test plus isServer: false plus an origin. That happens to suit vitest, and it's how we got our tests passing again. But anyone driving the router from a plain Node script, or a test runner that doesn't set NODE_ENV, has no way out. They also get no warning. navigate() just finishes quietly and nothing changes.

For that reason I'd prefer your second option: only skip navigation when the router is actually using the SSR history, not whenever it happens to be running in Node. That would bring back the old behaviour without anyone needing a flag.

If the current behaviour is deliberate, then a warning in development when a navigation gets thrown away would help a lot. So would a line in the SSR docs explaining what it takes to opt out.

We're no longer blocked, so this isn't urgent for us. Happy to leave the call to the maintainers.

The gist README has the full test table if anyone wants the detail.