[@hono/node-server] How to deal with ERR_HTTP_HEADERS_SENT errors?

[tlaziuk]

Hey, I have an application that has been using express and I'd like to replace it with hono, but in the development mode the app is using 3 express middlewares (webpack-dev-middleware, webpack-hot-middleware and connect-history-api-fallback) that I can not simply "drop".

The thing is each time I allow the hono middleware to resolve, the ERR_HTTP_HEADERS_SENT error is being thrown. The only solution that I've figured is to leak memory by not resolving the middleware:

  app.use(
    async (c, next) => {
      try {
        const { resolve, reject, promise: deferred } = defer<void>()

        const {
          incoming,
          outgoing,
        } = c.env

        outgoing.once('finish', reject)

        await devMiddleware(
          incoming,
          outgoing,
          resolve,
        )
        
        // @todo handle the `error` from the express middleware next here
        await deferred

        // `deferred` is resolved, it means `next` has been called in the express middleware, so hono's next can also be called
        await next()
      } catch (error) {
        // request has been handled by the express middleware, how to signal that to hono?

        // this will never resolve, ergo the request will never be full handled by hono, but that's a memory leak
        return new Promise<void>(() => {})
      }
    },
  )

As you may suspect doing so is not the most optimal solution. But is there another, recommended way of handling express/connect middlewares?

[EthanShoeDev]

I have the same issue with tinaCMS.

That library creates a handler() function that accepts an IncomingMessage and a ServerResponse (raw node http types).

I want to be able to use hono for the routing but it always fails with ERR_HTTP_HEADERS_SENT because hono tries to write to the already sent response after the tina handler is complete.

I believe this could be avoided if the responseViaResponseObject() function would check to see if the ServerResponse is finished before writing to it.

https://github.com/honojs/node-server/blob/dd0e0cd160b0b8f18abbcb28c5f5c39b72105d98/src/listener.ts#L54

[EthanShoeDev]

For further context, here is a code snippet.

const app = new Hono<{ Bindings: HttpBindings }>();

app.use(logger());
app.all("/api/tina/*", async (c) => {
  await handler(c.env.incoming, c.env.outgoing); // This calls c.env.outgoing.end()
});

serve({ fetch: app.fetch, port: 3000 }, (info) => {
  console.log(`Server running on http://localhost:${info.port}`);
});

After the tina handler the node hono adapter tries to add more (content length and such) to the response within responseViaResponseObject() even though response.finished is true.

[usualoma]

Hi @EthanShoeDev
Thanks for the comment!

For your example code, I think it would be better to have it return RESPONSE_ALREADY_SENT. (after honojs/node-server#153 is merged)

app.all("/api/tina/*", async (c) => {
  await handler(c.env.incoming, c.env.outgoing); // this calls c.env.outgoing.end()
  return RESPONSE_ALREADY_SENT
});

[yusukebe]

Hi @tlaziuk @EthanShoeDev Thanks!

Hi @usualoma ! If you have a time, please see this issue?

[usualoma]

How about the following solution? How about the following solution? I think this approach would solve this problem without compromising performance on general requests.
honojs/node-server#153

I understood that there are cases where one does not want to return a response from HONO, either in migration from an existing application or in special coordination with another application.

However, on the other hand, I believe that Hono does not want to recommend this kind of usage that strongly depends on the Node.js API.

Therefore, the PR above requires a rather long and verbose import { RESPONSE_ALREADY_SENT } from '@hono/node-server/utils/response'.

[tlaziuk]

Yes, that would solve the problem, thank you for your work!

[yusukebe]

Hi! Released @hono/node-server v1.9.0 that includes the feature by @usualoma .

[tlaziuk]

I tested the new version and it works as intended, thank you!

[EthanShoeDev]

Works great for TinaCMS as well. Thank you!