react-router request signal not relyable

[lauhon]

I'm using React Router as a...

framework

Context

I am building a loader function that returns a Stream Response to push information to the frontend in an interval as long as the connection is active. Keyword SSE (Server sent events)

Im getting inspiration from remix-utils and mdn

Reproduction

1. Open Stackblitz https://stackblitz.com/edit/github-mv51fdvk?file=app%2Froutes%2Fhome.tsx

2. Start in dev mode (or producation - bug is also there)

3. Visit preview to receive server-sent events on

• / - custom Stream implementation
• /remix-utils - eventStream using remix-utils

4. Close open tabs and inspect logs

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 20.19.1 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.8.2 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @react-router/dev: ^7.5.3 => 7.6.0 
    @react-router/node: ^7.5.3 => 7.6.0 
    @react-router/serve: ^7.5.3 => 7.6.0 
    react-router: ^7.5.3 => 7.6.0 
    vite: ^6.3.3 => 6.3.5

Used Package Manager

npm

Expected Behavior

When closing the tab the abort event should be triggered resulting in

1. Log output
2. a stop in the interval execution

Actual Behavior

When closing the tab the abort event is not triggered so the loop is continuing to run on both routes (/ and /remix-utils)

[lauhon]

Note: when trying the whole scenario out on my machine I get the expected behaviour as long as I open my app only with one tab.

As soon as there are multiple requests open at the same time, the signal starts to become unrelyable. I.e. some requests abort and others continue to run indefinitely

I started to experience this after I updated to react router 7 (from remix 2)

[brophdawg11]

Just to clarify, are you only referring to the signal being aborted when closing the tab? We currently abort the request if the express res triggers a close event without having triggered a finish event (link). You may be able to instrument that with some logging an get an idea of the order of events fired by express in the problematic scenario.

I ask to rule out this related question that comes up from time to time. From a client-side navigation standpoint, we only monitor the request and abort the signal during loader execution. Once the loaders have completed, the navigation is considered complete and subsequent navigations do not abort prior navigation request signals. See #10252 for a more in-depth explanation of the reasoning here.

[lauhon]

Hey @brophdawg11

I added some context to the original description.

So far I am only talking about closing tabs, but I could imagine that there are other scenarios where the connection is closed and the Abort signal doesn't get through.

The main point of my ticket is that SSE is a core web mechanic, but the currently best documented approach (remix-utils eventStream & abortSignal) causes a memory leak situation because the iteration never stops even when connections are closed.

If a server keeps running for a long time it will potentially start a lot of loops, but they are never stopped

Here is a example implementation of SSE from mdn. Basically what we need is a mechanism like if ( connection_aborted() ) break; to stop the loop.

This is provided as soon as the abort signal reaches the loader every time a connection is closed.

I will create a log that shows which events are emitted / not emitted

[lauhon]

Update:
I tested the code you mentioned locally.

We currently abort the request if the express res triggers a close event without having triggered a finish event (link).

I was able to verify the "close" event is actually always fired and the AbortSignal is always triggered. But somehow, event listeners in the loader function are not picking up the emitted event, which is causing the original problem I described.

I was even able to modify the remix request context to include the response object, and re-fire the abort signal manually, which relyably shuts down open intervals.

app.ts

import express from "express";
import "react-router";
import { createRequestHandler } from "./request";

declare module "react-router" {
  interface AppLoadContext {
    VALUE_FROM_EXPRESS: string;
     res: express.Response;
  }
}

export const app = express();

app.use((req, res, next) => {
  return createRequestHandler({
    build: () => import("virtual:react-router/server-build"),
    getLoadContext() {
      return {
        res,
        VALUE_FROM_EXPRESS: "Hello from Express",
      };
    },
  })(req, res, next);
});

home.tsx

export async function loader(args: Route.LoaderArgs) {
  console.log("REQUEST STARTING");

  const { request, context } = args;

  context.res.on("close", () => {
    console.log("CUSTOM RESPONSE CLOSE EVENT");
    request.signal.dispatchEvent(new Event("abort"));
  });

  return createStream(request.signal);
}

[mkromann]

I have the extract same issue. But @lauhon , your 'workaround' seems to work for me as well. Hope it is sustainable.

I am a little confused. Is it intended that closing a tab and reloading is not always triggering the cleanup function?

[michalmo]

Same issue, also want to add that using the browser back button causes the signal not to fire

[lukasa1993]

hello, maybe we need to listen to req.on close as well? since res may not started answering yet before tab is closed ?

https://discord.com/channels/770287896669978684/770287896669978687/1375420776429387827