early response on error instead of proceeding with the lifecycle using next

[salmanm]

No description provided.

[mcollina]

Can you add a unit test? Also I think we should call next(err).

[salmanm]

I think calling next(err) would let it continue the request life cycle and eventually land up in the same situation. Wouldn't it?

[salmanm]

I suppose in this case (missing auth header), we should be doing an early response from the hook. I don't think the control should ever reach the handler. I did test it locally and found it working. (Unless I've missed some case you're thinking)

I'll add a unit test as soon as we come to a conclusion on this.

[mcollina]

I suppose in this case (missing auth header), we should be doing an early response from the hook. I don't think the control should ever reach the handler. I did test it locally and found it working. (Unless I've missed some case you're thinking)

That's true, right. We shouldn't call next() at all.

[salmanm]

Added a test to ensure the correct response.

[delvedor]

Hello! I fear I'm missing the issue here. We are already doing that internally.
https://github.com/fastify/fastify/blob/master/lib/hooks.js#L65-L68
https://github.com/fastify/fastify/blob/master/fastify.js#L326-L329
https://www.fastify.io/docs/latest/Lifecycle/

[salmanm]

https://www.fastify.io/docs/latest/Hooks/#respond-to-a-request-from-a-hook

If needed, you can respond to a request before you reach the route handler.

Isn't this a use case of the above pattern? We're in preHandler and we don't want the life cycle to be continued because user isn't authenticated. If we let it continue, the custom setErrorHandler (if set) kicks in and converts the 401 to 500 response.

[salmanm]

Closing as its fixed in #9