You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Crash when using with fastify-http-proxy websockets #314
I have searched existing issues to ensure the bug has not already been reported
Fastify version
4.20.0
Plugin version
8.2.0
Node.js version
16.18.1
Operating system
Linux
Operating system version (i.e. 20.04, 11.3, 10)
22.04
Description
Adding both a websocket endpoint and a proxy to a websocket endpoint doesn't work. Error seems mostly the same as fastify/fastify-websocket#249. If I switch around the order I add the proxy and websocket endpoint, I can get it to log the error and continue instead of just crashing, but still doesn't work.
Error [ERR_INTERNAL_ASSERTION]: This is caused by either a bug in Node.js or incorrect usage of Node.js internals.
Please open an issue with this stack trace at https://github.com/nodejs/node/issues
at new NodeError (node:internal/errors:387:5)
at assert (node:internal/assert:14:11)
at ServerResponse.assignSocket (node:_http_server:280:3)
at Server.<anonymous> (/home/msundvick/Documents/simulator/sgpsim/node_modules/@fastify/http-proxy/index.js:91:19)
at Server.emit (node:events:525:35)
at Server.emit (node:domain:489:12)
at onParserExecuteCommon (node:_http_server:772:14)
at onParserExecute (node:_http_server:686:3) {
code: 'ERR_INTERNAL_ASSERTION'
}
Unfortunately @fastify/websocket and @fastify/http-proxy are incompatible. Long story short, they "plug" into the same event listener on the http server and must do different things to do their job.
Some reconciliation might be possible long term, but it's a significant amount of work that I do not have the bandwidth to take on. If anybody is willing, I would love to see this investigated and fixed.
Unfortunately @fastify/websocket and @fastify/http-proxy are incompatible. Long story short, they "plug" into the same event listener on the http server and must do different things to do their job.
Some reconciliation might be possible long term, but it's a significant amount of work that I do not have the bandwidth to take on. If anybody is willing, I would love to see this investigated and fixed.
I re-tested on the released versions (Fastify 5.12.5, @fastify/http-proxy 11.6.3, @fastify/websocket 11.3.1, Node 22) and the bug is still there: registering @fastify/websocket before the proxy still crashes with ERR_HTTP_SOCKET_ASSIGNED (same failure as ERR_INTERNAL_ASSERTION on Node 16). In the opposite order it only works because @fastify/websocket catches the error and logs a warning on every upgrade. Reopening.
Activity
mcollina commentedon Jul 26, 2023
I've transfered this to fastify-http-proxy because that's where the core of the issue is.
mcollina commentedon Jul 26, 2023
Unfortunately
@fastify/websocketand@fastify/http-proxyare incompatible. Long story short, they "plug" into the same event listener on the http server and must do different things to do their job.Some reconciliation might be possible long term, but it's a significant amount of work that I do not have the bandwidth to take on. If anybody is willing, I would love to see this investigated and fixed.
fastify/fastify-websocket#249 was correctly fixed there, the problem relies on this module now.
eze-nonso commentedon Sep 23, 2024
I could take this on, but I'd need more info on how this reconciliation should look like
Tony133 commentedon Sep 26, 2026
I re-tested on the released versions (Fastify 5.12.5,
@fastify/http-proxy11.6.3,@fastify/websocket11.3.1, Node 22) and the bug is still there: registering@fastify/websocketbefore the proxy still crashes withERR_HTTP_SOCKET_ASSIGNED(same failure asERR_INTERNAL_ASSERTIONon Node 16). In the opposite order it only works because@fastify/websocketcatches the error and logs a warning on every upgrade. Reopening.Create PR here: #486
fix: coexist with @fastify/websocket regardless of registration order
Tony133 commentedon Sep 30, 2026
Fixed in #486. If any problems arise, feel free to open a new issue with a minimal reproduction in a Git repository we can clone.