Prerequisites

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

🚀 Feature Proposal

If a URL handler uses async/await and does not return the reply object, then this will silently break the application in a manner very hard to debug.

Please see #4908 and possibly #3994

EG this code:

   app.get(
        "*",
        async (req, reply) => {
          reply.send("hello");
        }
    );

The solution is documented here but the problem is easily overlooked.

The correct answer is to either (a) return reply (b) return reply.send(...), or (c) await reply, however if you use the code above fastify/your app will call reply.send twice, causing the underlying HTTP implementation to throw an error.

It is virtually impossible to determine what caused the exception to be thrown by the underlying node HTTP library, even by debugging the fastify code.

From an end users point of view, the data has been sent (ie reply.send() has been called) and all promises have been awaited for - but gotcha! we have to know to await something not generally considered to be a promise, or return it.

Are there any circumstances when a URL handler can return a promise which resolves as undefined? AIUI the only time would be if the handler used await reply already.

It would be massively more helpful to detect a return of undefined and warn the user that is probably not correct, and then to await reply before continuing.

Motivation

The silent killer nature of this problem (which exhibits itself as an exception thrown by the underlying node http library) means that there is no clue as to the problem.

Example

No response