Reply was already sent, did you forget to "return reply" in /

[leonied7]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

5.3.0

Plugin version

12.1.0

Node.js version

22.12.0

Operating system

macOS

Operating system version (i.e. 20.04, 11.3, 10)

all

Description

Given the simple target and proxy service:

const target = fastify();

target.get('/', (request, reply) => {
  setTimeout(() => {
    reply.send('hello');
  }, 5000);
});

target.listen({ port: 0 });

const proxy = fastify({
  logger: true
});
proxy.register(fastifyReplyFrom);

proxy.addHook('onRequest', (request, reply) => {
  return reply.from(`http://localhost:${target.server.address().port}/`);
});

proxy.listen({ port: 53347 })

Send request to GET http://localhost:53347/ and abort it before the target answering

The proxy try to send answer after answering from the target

Link to code that reproduces the bug

Expected Behavior

A warning not happend

[leonied7]

I have an idea:

Add a AbortController into each reply.from call and abort it on connection close. For example:

fastify.decorateReply('from', function (source, opts) {
 // ...
  const abortController = new AbortController();
  this.request.raw.once('close', () => {
    if (!this.sent) {
      this.status(499).send();
    }
    abortController.abort();
  });
 requestImpl({ method, url, qs, headers: requestHeaders, body, timeout, signal: abortController.signal }, (err, res) => {
 // ...
})

What do you think about it?

[leonied7]

Additional info: The stream that was sent by Target will not be closed.

[mcollina]

I would avoid the use of AbortController as it kind of expensive. However, we should be able to check the state of the underlining request, and if has been closed/aborted - avoid sending down the request completely.

Note that this might actually be a small problem in Fastify itself.

[gunters63]

Could this probably be fixed together with #424?