Commits on Aug 3, 2022

1. Ensure that setErrorHandler functions run for errors thrown before th… …

   …e websocket is upgraded
   
   `fastify-websocket` has rich support for running requests through the router and hooks before actually upgrading them to full duplex websocket connections outside the normal HTTP lifecycle. Hooks are useful for auth, sessions, tracing, etc etc, and so we take care to make the request look as normal as possible until we `reply.hijack()` and take over.
   
   Before this change, the `onError` hook that `fastify-websocket` was registering was very eagerly handling errors encountered during the hook chain. The `onError` hook would run *before* any error handlers added by `.setErrorHandler`, and it would by-default upgrade the request to dispatch a close code. This changed with the upgrade to fastify v4 -- before, any error in a hook would run the `.setErrorHandler` errors first, which would probably reply.send, and the request would never get hijacked.
   
   I think the prior behaviour is better for two reasons. First, hook code that is doing auth or sessions or tracing or whatever is going to tend to presume it can `reply.send` to report an error. I think we should let it instead of having to make every error handler in your app be websocket aware. And second, it is likely to reply.send with a useful response because it is the endorsed way of reporting errors, whereas fastify-websocket's default error handling doesn't really know much about what to do in the face of errors and handles them really generically.
   
   The good news is restoring the fastify v3 behaviour for this module is easy -- we just delete the `onError` event handler from this library. I think it never really made sense after we switched to dispatching requests through the fastify before upgrading them -- in that phase, the request isn't yet special. We let fastify's normal error event handling do it's thing before the request gets upgraded. The behavior after upgrade is unchanged, which is to run the websocket specific error handler passed in as an option to this plugin.
   
   Also of note that without making this change, if you `reply.send` in a `setErrorHandler` error handler, you end up double sending because the `.onError` hook hijacks the reply, and then your `setErrorHandler` code runs and encounters `FST_ERR_REP_ALREADY_SENT`. Here's the log of me running the new test this PR adds on the old code:
   
   ```
   test/hooks.js 1> [1659567917980] INFO (59599 on claw.localdomain): Server listening at http://127.0.0.1:50104
   test/hooks.js 1> [1659567917981] INFO (59599 on claw.localdomain): Server listening at http://[::1]:50104
   test/hooks.js 1> [1659567917991] INFO (59599 on claw.localdomain): incoming request
   test/hooks.js 1>     reqId: "req-1"
   test/hooks.js 1>     req: {
   test/hooks.js 1>       "method": "GET",
   test/hooks.js 1>       "url": "/echo",
   test/hooks.js 1>       "hostname": "localhost:50104",
   test/hooks.js 1>       "remoteAddress": "127.0.0.1",
   test/hooks.js 1>       "remotePort": 50105
   test/hooks.js 1>     }
   test/hooks.js 1> [1659567917993] ERROR (59599 on claw.localdomain): Fail
   test/hooks.js 1>     reqId: "req-1"
   test/hooks.js 1>     err: {
   test/hooks.js 1>       "type": "Error",
   test/hooks.js 1>       "message": "Fail",
   test/hooks.js 1>       "stack":
   test/hooks.js 1>           Error: Fail
   test/hooks.js 1>               at Object.<anonymous> (/Users/airhorns/Code/fastify-websocket/test/hooks.js:94:13)
   test/hooks.js 1>               at processTicksAndRejections (node:internal/process/task_queues:96:5)
   test/hooks.js 1>     }
   test/hooks.js 1> [1659567917996] WARN (59599 on claw.localdomain): Reply already sent
   test/hooks.js 1>     reqId: "req-1"
   test/hooks.js 1>     err: {
   test/hooks.js 1>       "type": "FastifyError",
   test/hooks.js 1>       "message": "Reply was already sent.",
   test/hooks.js 1>       "stack":
   test/hooks.js 1>           FastifyError: Reply was already sent.
   test/hooks.js 1>               at Reply.send (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/reply.js:118:26)
   test/hooks.js 1>               at Object.<anonymous> (/Users/airhorns/Code/fastify-websocket/test/hooks.js:99:29)
   test/hooks.js 1>               at handleError (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/error-handler.js:58:18)
   test/hooks.js 1>               at /Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/reply.js:670:13
   test/hooks.js 1>               at done (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/hooks.js:213:7)
   test/hooks.js 1>               at Object.<anonymous> (/Users/airhorns/Code/fastify-websocket/index.js:93:5)
   test/hooks.js 1>               at next (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/hooks.js:219:30)
   test/hooks.js 1>               at onSendHookRunner (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/hooks.js:241:3)
   test/hooks.js 1>               at onErrorHook (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/reply.js:665:5)
   test/hooks.js 1>               at Reply.send (/Users/airhorns/Code/fastify-websocket/node_modules/fastify/lib/reply.js:124:5)
   test/hooks.js 1>       "name": "FastifyError",
   test/hooks.js 1>       "code": "FST_ERR_REP_ALREADY_SENT",
   test/hooks.js 1>       "statusCode": 500
   test/hooks.js 1>     }
   ```

   

   airhorns committed Aug 3, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for f0d75a2
   • Browse repository at this point

   Copy the full SHA

   f0d75a2 View commit details

   Browse the repository at this point in the history