Start: non-OK application/json response makes a server function resolve undefined instead of rejecting

[antur84]

Which project does this relate to?

Start

Describe the bug

A server-function call resolves with undefined when the response is not OK, is application/json, and has no x-tss-serialized header. .catch() never runs. The same 500 as text/plain rejects.

getResponse in start-client-core/src/client-rpc/serverFnFetcher.ts returns plain JSON before it checks response.ok:

if (contentType.includes('application/json')) {
  const jsonPayload = await response.json()
  const redirect = parseRedirect(jsonPayload)
  if (redirect) throw redirect
  if (isNotFound(jsonPayload)) throw jsonPayload
  return jsonPayload
}
if (!response.ok) {
  throw new Error(await response.text())
}

The middleware in createServerFn.ts spreads that body into the call context and returns result.result, so an error body without a result key becomes undefined. A body with an error key is thrown as-is.

Any JSON error response between browser and server does this: a gateway 502 page, a proxy, or the server's own unhandled 500 when x-tsr-serverFn is missing (#8237).

Complete minimal reproducer

https://github.com/antur84/tanstack-start-serverfn-nonok-json-repro

Steps to Reproduce the Bug

1. pnpm install && pnpm build && pnpm start
2. Open http://localhost:3000/?mode=json500. The fetch returns a 500 JSON body. The loader resolves with undefined.
3. Open http://localhost:3000/?mode=text500. Same 500 as text/plain. The loader rejects.
4. Open http://localhost:3000/?mode=noheader. Real request without x-tsr-serverFn. The server answers {"status":500,"unhandled":true,"message":"HTTPError"}, the loader resolves with undefined.

Expected behavior

A non-OK response that Start did not serialize should reject, like the text/plain path:

if (!response.ok) throw new Error(JSON.stringify(jsonPayload))

Screenshots or Videos

None, the banner on each page shows the outcome.

Platform

@tanstack/react-start 1.168.50, @tanstack/react-router 1.170.33 (start-client-core 1.170.28, start-server-core 1.169.32, router-core 1.171.28), vite 8.2.2, node 24, macOS. Same code on main.

Additional context

Fixing #8237 does not close this. Any JSON error body takes the same path.

[schiller-manuel]

the reproducer does not make sense to me. why would you override fetch with something that returns a response without calling the server and return non-conforming responses?

[antur84]

the reproducer does not make sense to me. why would you override fetch with something that returns a response without calling the server and return non-conforming responses?

I just went quick and dirty to provoke the issue, sry. I changed to a faked api gateway in in the middle now, gateway.mjs.

Note that I'm just reporting that the error handling has an edge case (e.g. seen during La Liga matches when spain blocks their internet to prevent piracy streams) where my client .catch() doesn't run, the triggering error itself is not tanstack related.

Feel free to close if not deemed relevant, we've handled these with undefined checks.

[quanglam2807]

Some corroboration for the "intermediary returns non-conforming responses" framing, since that got questioned above — it is not a contrived scenario.

We hit this in production on Cloudflare Workers when Cloudflare's bot management began serving managed challenges and 403s to /_serverFn/*. Server-function calls are same-origin fetch(), so they can never satisfy an interstitial. The challenge body names the intercepted path:

cType: 'managed', cUPMDTk: "/_serverFn/c29844191716252ad5d6ebe1cf8a3d5443549155d94a720b2239f3e2d46e76c0?__cf_chl_tk=..."

One call site produced three different symptoms depending on what Cloudflare returned:

Intermediary response	Symptom
non-2xx text/html	Error whose message is the whole HTML body
2xx text/html	loader data is a Response; component throws .map is not a function
non-2xx application/json	resolves undefined — this issue

So the JSON case you reported is one of three branches of the same gap: getResponse trusts responses that carry neither x-tss-serialized nor x-tss-raw, even though the server tags everything it produces (server-functions-handler.ts L172-180, the isRedirect branch aside).

I filed #8333 for the 2xx branch. Worth noting for whoever picks these up: the fix proposed here (if (!response.ok) throw before the JSON return) would not cover it, since that case is a 200 and returns at L340. Rejecting any untagged response would close both.