Hono•2w ago

Invalid state: ReadableStream is already closed

Hello here, I am starting to suspect something odd in @hono/node-server We have random ReadableStream is already closed in the app, everything is try/catch but anyway it crashes the container. We are also using GraphQL Yoga, I found out about this: https://github.com/honojs/node-server/issues/77 But I hesitate to do that because GraphQL Yoga is using @whatwg-node/fetch which is supposed to be a good abstraction. the full trace is:

node:internal/webstreams/readablestream:1162
throw new ERR_INVALID_STATE.TypeError('ReadableStream is already closed');
^
TypeError [ERR_INVALID_STATE]: Invalid state: ReadableStream is already closed
at ReadableByteStreamController.close (node:internal/webstreams/readablestream:1162:13)
at node:internal/deps/undici/undici:1480:28
at node:internal/process/task_queues:151:7
at AsyncResource.runInAsyncScope (node:async_hooks:211:14)
at AsyncResource.runMicrotask (node:internal/process/task_queues:148:8)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
code: 'ERR_INVALID_STATE'
}
Node.js v22.13.1

node:internal/webstreams/readablestream:1162
throw new ERR_INVALID_STATE.TypeError('ReadableStream is already closed');
^
TypeError [ERR_INVALID_STATE]: Invalid state: ReadableStream is already closed
at ReadableByteStreamController.close (node:internal/webstreams/readablestream:1162:13)
at node:internal/deps/undici/undici:1480:28
at node:internal/process/task_queues:151:7
at AsyncResource.runInAsyncScope (node:async_hooks:211:14)
at AsyncResource.runMicrotask (node:internal/process/task_queues:148:8)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
code: 'ERR_INVALID_STATE'
}
Node.js v22.13.1

Of course I don't reproduce easily, it happens randomly Any idea? to identify the problem better?

12 Replies

Sébastien MorelOP•2w ago

I know that this error, is usually associated with double read of a Response (.json(), .text()) etc. etc. but that's not the case here

Arjix•2w ago

do you have middleware that modifies the response?

Sébastien MorelOP•2w ago

hey @Arjix I have a middleware that adds header to the response yes, and then I do that in the app

const response = await yoga.handleRequest(c.req.raw, {
        env: c.env,
        ctx: c,
      })
      response.headers.forEach((value, key) => {
        c.res.headers.set(key, value)
      })
      c.res.headers.set('Vary', 'Accept-Encoding')

      try {
        return c.body(response.body!, response.status as ContentfulStatusCode)
      } catch (error) { /**}

const response = await yoga.handleRequest(c.req.raw, {
        env: c.env,
        ctx: c,
      })
      response.headers.forEach((value, key) => {
        c.res.headers.set(key, value)
      })
      c.res.headers.set('Vary', 'Accept-Encoding')

      try {
        return c.body(response.body!, response.status as ContentfulStatusCode)
      } catch (error) { /**}

Sébastien MorelOP•2w ago

I wonder if the culprit is not: https://github.com/honojs/node-server/blob/main/src/request.ts#L83 but I don't explain it

GitHub

node-server/src/request.ts at main · honojs/node-server

Node.js Server for Hono. Contribute to honojs/node-server development by creating an account on GitHub.

Sébastien MorelOP•2w ago

and I can't reproduce it yet

Arjix•2w ago

can you give an example repo with yoga + hono? so I can reproduce the issue

Sébastien MorelOP•2d ago

if only I could reproduce all is working fine locally it happened 10 times today in our prod I wonder if resource exhaustion could trigger something that would trigger that We tried to change the fetch implementation but nothing changed really same trace

ambergristle•2d ago

have you tried reproducing on a minimal deployed example?

Sébastien MorelOP•2d ago

I can't reproduce it. it's when we have high volume traffic, not connect to resource exhaustion or anything. But we see a correlation with number of api calls I tried to force reproduce it by bombarding our staging env, I killed the container(s) without reproducing this ReadableStream error and the trace does not say exactly where it crashes so that does not help

ambergristle•2d ago

"reproduce" doesn't only mean to trigger the error intentionally in this case, a minimal reproducible example might be something like a project with a single endpoint and the dependencies you're using, that fails with the same error in deployment based on what you've shared so far, we have no way to know whether the error is in one of your dependencies, or in your code, deployment config, etc.

Sébastien MorelOP•2d ago

yes I know and understand that... just not really easy to provide something that would make sense. Any idea in the code of Hono where a ReadableByteStreamController.close would be done and not try /catch / handle ?

ambergristle•2d ago

If you can’t provide a reproducible example, idk how much help I can be If you’re convinced the problem is internal to Hono, you should open an Issue, but the maintainers are going to ask for an example too Trying to troubleshoot/debug without context or reference is really difficult, and the truth is that most bugs are in developer implementations, not the underlying libraries I can try and help you troubleshoot your project, but it will basically be trial and error

Gaming

Programming

Invalid state: ReadableStream is already closed

Did you find this page helpful?