Throwing error in route loader with SSR streaming crashes dev server

[yanghuidong]

Which project does this relate to?

Start

Describe the bug

When streaming loader data during SSR, which is activated by neither awaiting nor returning the fetched data, an error thrown by the fetcher (e.g. Zod validation error) will crash the Vite dev server (with Nitro v3 plugin, Cloudflare Workers preset). Now if we don't enable streaming, then the error is properly caught by the default error component of the router, and the dev server doesn't crash.

Your Example Website or App

Not available yet, but very minimal code to reproduce locally, see below

Steps to Reproduce the Bug or Issue

Here's a minimal example to reproduce the scenario:

const ARTICLES_PER_PAGE = 0; // Invalid input according to Zod schema

export const Route = createFileRoute('/')({
	loader: async ({ context }) => {
		const data = context.queryClient.ensureQueryData(
			articlesQueryOptions(0, ARTICLES_PER_PAGE),
		);
		// return data; // not returning gives us streaming behavior according docs
	},
	component: HomePage,
});

When we don't return (nor await) the data, opening the page immediately crashed the dev server. The server console prints the following:

[4:39:14 PM]  ERROR  Worker error: [
  {
    "origin": "number",
    "code": "too_small",
    "minimum": 1,
    "inclusive": true,
    "path": [
      "limit"
    ],
    "message": "Too small: expected number to be >=1"
  }
]

    at execValidator (node_modules/.pnpm/@tanstack+start-client-core@1.142.13/node_modules/@tanstack/start-client-core/src/createServerFn.ts:673:13)
    at next (node_modules/.pnpm/@tanstack+start-client-core@1.142.13/node_modules/@tanstack/start-client-core/src/createServerFn.ts:196:24)
    at executeMiddleware (node_modules/.pnpm/@tanstack+start-client-core@1.142.13/node_modules/@tanstack/start-client-core/src/createServerFn.ts:233:10)
    at AsyncFunction.listPublicArticlesFn.__executeServer (node_modules/.pnpm/@tanstack+start-client-core@1.142.13/node_modules/@tanstack/start-client-core/src/createServerFn.ts:147:20)
    at src/server/query.ts:238:10
    at Object.fn [as extractedFn] (node_modules/.pnpm/@tanstack+start-server-core@1.142.13_crossws@0.4.1_srvx@0.9.7_/node_modules/@tanstack/start-server-core/src/createSsrRpc.ts:15:12)
    at client (node_modules/.pnpm/@tanstack+start-client-core@1.142.13/node_modules/@tanstack/start-client-core/src/createServerFn.ts:705:21)
    at queryFn (src/tsq.ts:36:11)

node:internal/deps/undici/undici:13510
      Error.captureStackTrace(err);
            ^

TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at async nitroDevMiddleware (node_modules/.pnpm/nitro@3.0.1-alpha.1_@libsql+client@0.15.15_drizzle-orm@0.45.0_@libsql+client@0.15.15_ky_639768f3d07319a3d1fe53facc673f3e/node_modules/nitro/dist/_build/vite.plugin.mjs:348:18) {
  [cause]: SocketError: other side closed
      at Socket.onHttpSocketEnd (node_modules/.pnpm/undici@7.16.0/node_modules/undici/lib/dispatcher/client-h1.js:904:22)
      at Socket.emit (node:events:530:35)
      at endReadableNT (node:internal/streams/readable:1698:12)
      at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
    code: 'UND_ERR_SOCKET',
    socket: {
      localAddress: undefined,
      localPort: undefined,
      remoteAddress: undefined,
      remotePort: undefined,
      remoteFamily: undefined,
      timeout: undefined,
      bytesWritten: 791,
      bytesRead: 0
    }
  }
}

Node.js v22.18.0
 ELIFECYCLE  Command failed with exit code 1.

Now, as soon as we switch to returning the data, the dev server crash stops, and the browser renders the default ErrorComponent defined on the router.

Expected behavior

Ideally, turning on SSR streaming wouldn't make the (dev) server less robust than in non-streaming mode.

Screenshots or Videos

No response

Platform

• Router / Start Version: 1.142.13
• OS: macOS
• Browser: Chrome
• Browser Version: 144.0
• Bundler: Vite
• Bundler Version: 7.3.0

Additional context

Using "nitro": "3.0.1-alpha.1" with preset: 'cloudflare_module'

Relevant quote from docs:

You can also prefetch with fetchQuery or ensureQueryData in a loader without consuming the data in a component. If you return the promise directly from the loader, it will be awaited and thus block the SSR request until the query finishes. If you don't await the promise nor return it, the query will be started on the server and will be streamed to the client without blocking the SSR request.

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Related PRs

#5363 - examples: Add a new TanStack Start example for typed readable streams [merged]
#5518 - Solid hydration [merged]
#5647 - test(solid-start): fix dev server for suspense transition [merged]
#5837 - docs(solid-start): add start-streaming-data-from-server-functions example [merged]
#5994 - fix: fix streaming [merged]

👤 Suggested Assignees

• birkskyum
• fulopkovacs
• brenelz
• schiller-manuel

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[schiller-manuel]

can you please try again with latest?

[zaidhaan]

this looks to be a duplicate of #5589. and yes, still exists in latest release (v1.143.12).

i'm skeptical that this issue is specific to streaming though, i was able to reproduce this in latest v1.143.12 with both streaming and default rendering mode, with a route looking like this:

export const Route = createFileRoute('/load')({
  component: RouteComponent,
  loader: () => {
    Promise.resolve().then(() => {
      throw new Error("boom")
    });
  }
})

[yanghuidong]

can you please try again with latest?

Just did, here's the new versions I'm using:

		"@tanstack/solid-query": "5.90.15",
		"@tanstack/solid-query-devtools": "5.91.1",
		"@tanstack/solid-router": "1.143.6",
		"@tanstack/solid-router-devtools": "1.143.6",
		"@tanstack/solid-router-ssr-query": "1.143.7",
		"@tanstack/solid-start": "1.143.12",
		"nitro": "3.0.1-alpha.1",
		"solid-js": "1.9.10",

The behavior is exactly the same as before:

• with return data in loader, Zod error is caught in the default error component of the router, no crashing at all;
• as soon as I comment out return data, dev server crashes on page reload (but not on Vite HMR).

I did notice some differences in the stack trace, so I'll include it here fyi:

[2:41:14 PM]  ERROR  Worker error: [
  {
    "origin": "number",
    "code": "too_small",
    "minimum": 1,
    "inclusive": true,
    "path": [
      "limit"
    ],
    "message": "Too small: expected number to be >=1"
  }
]

    at execValidator (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:719:13)
    at callNextMiddleware (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:220:26)
    at executeMiddleware (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:311:10)
    at AsyncFunction.__executeServer (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:154:34)
    at src/server/query.ts?tss-serverfn-split:233:5
    at Object.fn [as extractedFn] (node_modules/.pnpm/@tanstack+start-server-core@1.143.12_crossws@0.4.1_srvx@0.9.7_/node_modules/@tanstack/start-server-core/src/createSsrRpc.ts:15:12)
    at client (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:751:21)
    at callNextMiddleware (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:271:24)
    at Object.assign (node_modules/.pnpm/@tanstack+start-client-core@1.143.12/node_modules/@tanstack/start-client-core/src/createServerFn.ts:116:26)
    at queryFn (src/tsq.ts:53:11)

node:internal/deps/undici/undici:13510
      Error.captureStackTrace(err);
            ^

TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at async nitroDevMiddleware 
...

[yanghuidong]

Latest version shows cleaner stack trace:

		"@tanstack/solid-query": "5.90.18",
		"@tanstack/solid-query-devtools": "5.91.2",
		"@tanstack/solid-router": "1.144.0",
		"@tanstack/solid-router-devtools": "1.144.0",
		"@tanstack/solid-router-ssr-query": "1.144.0",
		"@tanstack/solid-start": "1.145.1",

[5:13:33 PM]  ERROR  Worker error: [
  {
    "origin": "number",
    "code": "too_small",
    "minimum": 1,
    "inclusive": true,
    "path": [
      "limit"
    ],
    "message": "Too small: expected number to be >=1"
  }
]

    at execValidator (node_modules/.pnpm/@tanstack+start-client-core@1.145.0/node_modules/@tanstack/start-client-core/src/createServerFn.ts:716:13)
    at callNextMiddleware (node_modules/.pnpm/@tanstack+start-client-core@1.145.0/node_modules/@tanstack/start-client-core/src/createServerFn.ts:220:20)

node:internal/deps/undici/undici:13510
      Error.captureStackTrace(err);
            ^

TypeError: fetch failed
    at node:internal/deps/undici/undici:13510:13
    at async nitroDevMiddleware (node_modules/.pnpm/nitro@3.0.1-alpha.1_@libsql+client@0.15.15_drizzle-orm@0.45.0_@libsql+client@0.15.15_ky_639768f3d07319a3d1fe53facc673f3e/node_modules/nitro/dist/_build/vite.plugin.mjs:348:18) {
  [cause]: SocketError: other side closed
...

[yanghuidong]

btw this is the error from the GET request as seen in a Cloudflare Workers deployment:

A query that was dehydrated as pending ended up rejecting. [["articles","public",0,1]]: Error: [
  {
    "origin": "number",
    "code": "too_small",
    "minimum": 1,
    "inclusive": true,
    "path": [
      "limit"
    ],
    "message": "Too small: expected number to be >=1"
  }
]; The error will be redacted in production builds