`TypeError: Load failed` causing crashes on WebKit browsers

[wiebekaai]

Hey there,

Nice to meet some of you at the DotDev event :).

We've built a storefront for an enterprise client that I'm super happy with, but there's an issue that appears in our logs that I can't reproduce. It crashes the frontend, showing an error boundary in 0.79% of sessions, which is way too much at our scale.

I have attached the production logs. Here's what I've found:

• Only in WebKit browsers
• A fetch request to a .data fetch request is logged with statusCode=0
• Server-side logs for the same sessions return successfully with statusCode=200
• Error boundary shows, crashing the page

I hope you can help us understand why a successful server response isn't reaching the user. And is there a way to handle this more gracefully?

I can't share our codebase publicly, but I'd be happy to walk you through it. It's very close to the Hydrogen example. We do have a Cloudflare worker for traffic routing in front of Oxygen, but this doesn't cause any (other?) issues.

Kind regards,

Wiebe

Session logs

The logs include a status code of 500 for the client-side error boundary because we labeled it that way in our frontend code. It's not an actual 500. Confusing, I know.

session-4afd71d9-pdp-predictive.csv
session-9d7b0c22-login-navigation-2.csv
session-70e0a899-cart-navigation.csv
session-820a2263-suits-predictive-search.csv
session-3884a2e6-stores-navigation.csv
session-4034dfd8-plp-predictive.csv
session-de363bc6-home-predictive.csv
session-df00ab4f-search-predictive.csv
session-f3055940-login-navigation.csv
session-ffc52bc0-home-search-predictive.csv

Which package or tool is having this issue?

Hydrogen

What version of that package or tool are you using?

2026.4.2

What version of React Router 7 are you using?

7.15.1

[smirnov-artur]

The .data path in React Router 7 fails in three distinguishable ways, and which message you see narrows this down a lot — so it's worth pinning that down before chasing WebKit.

All three live in fetchAndDecodeViaTurboStream (single-fetch.tsx):

What you see	Where it comes from	What it means
TypeError: Load failed	the bare await fetch(...) at #L593 rejecting	no Response object was ever produced — it broke at or before response headers
ErrorResponse with a real status	#L602, status >= 400 without X-Remix-Response	reached something, got a 4xx/5xx from an intermediary
Unable to decode turbo-stream response	#L664, around decodeViaTurboStream(res.body) at #L637	headers did arrive, body was cut mid-stream

That last row is the one worth internalising: single fetch decodes res.body as a stream, so a connection that dies halfway through the body still gives you a Response and a 200, and only fails at decode time. If you were seeing that message, "server 200, client broken" would be self-explanatory.

You're seeing TypeError: Load failed with statusCode=0, which is the opposite case — the fetch promise rejected before any response existed, while the origin recorded a completed 200. Nothing in the app can produce that combination: by the time your loaders ran and the server logged 200, the client had already lost the connection. That points squarely at the hop in between — the Cloudflare Worker you have in front of Oxygen — rather than at Hydrogen or your route code. Worth checking whether the Worker re-pipes the response body (new Response(res.body, res)) versus buffering or cloning it; re-piping a streamed turbo-stream body through a Worker is an easy place to lose it, and it fails per-connection, not per-request, which is why it looks like an unreproducible ~1% rather than a broken route.

Two things you can measure without touching the app, since you already have session logging:

1. PerformanceResourceTiming for the failing .data URL. performance.getEntriesByName(url) gives you responseStart, responseEnd, transferSize, encodedBodySize. responseStart === 0 means it never got headers — network/TLS/proxy layer. responseStart > 0 with encodedBodySize short means mid-body truncation. That single number splits the two hypotheses.
2. Whether the tab was navigating. Your session names are dominated by predictive and navigation, so it's worth ruling out requests killed by the browser during unload. React Router does guard its own aborts — request.signal.aborted is checked throughout router.ts — so a supersede that it initiated shouldn't reach an ErrorBoundary; a browser-level cancellation is not guarded anywhere.

On "is there a way to handle this more gracefully" — not from inside React Router today. The document-load path is:

try {
  let data = await fetchAndDecode(args, targetRoutes);
  singleFetchDfd.resolve(data.data);
} catch (e) {
  singleFetchDfd.reject(e);   // #L452-L457
}

No retry, and no discrimination between an abort and a genuine transport failure — AbortError does not appear anywhere in the runtime source, only in tests. So every transport hiccup is promoted to a route error.

Until that changes, the interception point you own is your own ErrorBoundary: treat error instanceof TypeError (optionally with /load failed|network/i on the message) as transient rather than fatal, and re-attempt the navigation once instead of rendering the crash screen. At 0.79% of sessions, a single retry should take most of it, and it will also tell you how much of the remainder is genuinely unrecoverable — which is a far more useful number to bring back to this issue than the raw rate.

[frandiox]

@wiebekaai Hi 👋 Since these all happen on iOS and mostly for .data requests, the main suspicion I think is some sort of adblockers/rules on iOS. It seems it's a known thing in React Router: remix-run/react-router#14836

If that's the case, there's not much we can do at the Hydrogen level I think. cc @brophdawg11 any ideas?

As a possible temporary "workaround", perhaps you could detect these errors in the ErrorBoundary component and trigger a full page refresh? Not nice but at least it would self-recover 🤔

[brophdawg11]

Hm, no we have heard of this but it's never been widely reported enough to require any action. I would be curious if there's any recourse with the adblocker software themselves since it's really their false positive