Start: serverFnFetcher unconditionally console.logs every server-function error, including benign cancellation AbortErrors

[christopherschroer]

Which project does this relate to?

Start

Describe the bug

serverFnFetcher's getResponse logs every non-Response error thrown by a server-function call via console.log, then re-throws it. In packages/start-client-core/src/client-rpc/serverFnFetcher.ts:

async function getResponse(fn) {
  let response
  try {
    response = await fn()
  } catch (error) {
    if (error instanceof Response) response = error
    else {
      console.log(error)   // ← logs every error, incl. benign cancellations
      throw error
    }
  }
  // ...
}

Two problems:

1. It's unconditional — there is no process.env.NODE_ENV guard, so it also runs in production builds (bundlers don't strip console.log by default), spamming the browser console for real users.
2. It logs benign cancellations. When a caller passes an AbortSignal to a server function and aborts it (e.g. a request cancelled on navigation/unmount), the RPC fetch rejects with DOMException: signal is aborted without reason (AbortError). getResponse console.logs it and re-throws. The
   re-thrown error is then handled by the caller (who deliberately aborted and no longer cares about the result), so the throw itself is fine — but the console.log leaves a stray, stack-trace-bearing console entry with no context.

Because it's console.log (not console.error) on a caught-and-rethrown error, it can't be intercepted from application code: it never reaches a framework error hook or error boundary, and it isn't an unhandled promise rejection, so a window unhandledrejection listener doesn't catch it either.
The only app-side workarounds are monkey-patching console or patching the package.

Complete minimal reproducer

https://codesandbox.io/p/devbox/condescending-diffie-z59y9f

Steps to Reproduce the Bug

1. Start Dev Server
2. Open preview browser.
3. Click the button
4. examine browser dev console logs

Expected behavior

Cancelling a server-function call should not log to the console. More generally, getResponse should not console.log errors it re-throws — the caller is responsible for handling and reporting them. At minimum the log should be removed; if diagnostic logging is intended, gate it behind
process.env.NODE_ENV !== 'production' and skip cancellation errors (AbortError / CancelledError).

Screenshots or Videos

No response

Platform

• @tanstack/react-start 1.168.30 (@tanstack/start-client-core 1.170.13)
• React 19, Vite 8
• Browser: Chrome (reproduces in both dev and production builds)

Additional context

No response