(Framework mode) Rate limiting .data endpoints?

[xandris]

Hi all, I have server-side actions that should be rate limited. I can implement this with a web server (Hono) rate limiter, which returns 429 when triggered. This is the server-side behavior I wanted, but this approach causes the nearest ErrorBoundary to render. I gather this is because the rate limiter replies with a plain 429, whereas a const action = ... that returns data('too fast', {status: 429}) returns a serialized response and x-remix-response: yes header which lets a fetcher handle it instead.

I can work around the problem like this but it's terrible

const limiter = rateLimiter<Env>({
  keyGenerator: c => getConnInfo(c).remote.address ?? '',
  handler: c =>
    c.json([{ _1: 2 }, 'data', { _3: 4 }, 'message', 'too fast'], {
      status: 429,
      headers: {
        'x-remix-response': 'yes'
      }
    })
})

What is the intended solution? Route middleware? I could do that but I'd have to use a different rate limiter...

[MLuc24]

The behaviour you hit is deliberate, and the source comment names your exact case.

packages/react-router/lib/dom/ssr/single-fetch.tsx:

// If this error'd without hitting the running server, then bubble a normal
// `ErrorResponse` and don't try to decode the body with `turbo-stream`.
//
// This could be triggered by a few scenarios:
// - `.data` request 404 on a pre-rendered app using a CDN
// - 429 error returned from a CDN on a SSR app
if (res.status >= 400 && !res.headers.has("X-Remix-Response")) {
  throw new ErrorResponseImpl(res.status, res.statusText, await res.text());
}

From the client's side a 429 from your Hono limiter is indistinguishable from a 429 from a CDN sitting in front of the app: it never reached the React Router handler, so there is no serialized result to hand a fetcher, and bubbling to the ErrorBoundary is the only safe thing left. The X-Remix-Response header is set in packages/react-router/lib/server-runtime/single-fetch.ts only on responses React Router itself produced.

Which is also why I would not ship your workaround. That array isn't JSON with a funny shape — it's turbo-stream encoding, and the .data body is served as Content-Type: text/x-script. Hand-writing it pins you to an internal wire format with no compatibility guarantee; a patch release can change it and your rate-limit path breaks in a way that only shows up under load.

Middleware won't do what you want if you throw from it. From the middleware guide:

Just like when a action/loader throws, if a middleware throws it will be caught and handled at the appropriate ErrorBoundary

So throw data('too fast', { status: 429 }) in middleware lands you exactly where you already are.

Returning is a different path from throwing. A middleware may skip next() and return a result directly, and on the server a returned data() is upgraded to a Response — packages/react-router/lib/router/router.ts:

// A type predicate function to check if the values returned by the user without
// a next() call is of the proper type.  If so we use it directly, otherwise we
// call next() for them.
isResult: (v: unknown) => v is Result,

return isDataWithResponseInit(result)
  ? dataWithResponseInitToResponse(result)
  : result;

So the shape to try is return, not throw:

export const middleware: Route.MiddlewareFunction[] = [
  async ({ request, context }) => {
    if (await isRateLimited(request)) {
      return data("too fast", { status: 429 }); // no next() call
    }
  },
];

I have read the short-circuit and data()-upgrade paths in the source but have not run this end to end, so verify one thing in your app before committing to it: that the resulting .data response actually carries X-Remix-Response. If it does, your fetcher gets the 429 as data and no boundary renders.

The path that is guaranteed to work today is the boring one: do the limiter check inside the action and return data('too fast', { status: 429 }) there, since that is the flow single-fetch is built around. Keep the Hono limiter as the outer hard cap for abusive traffic, at a much higher threshold — a plain 429 hitting the ErrorBoundary is the correct outcome for a caller you are trying to shed, not a UX you need to polish. Both call the same limiter instance, so the policy stays in one place.