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
Linux 9dbe5639fcc3 5.15.0-1030-gcp #37~20.04.1-Ubuntu SMP Mon Feb 20 04:30:57 UTC 2023 x86_64 GNU/Linux (more specifically, Replit)
Subsystem
No response
What steps will reproduce the bug?
I've been trying to proxy HTTP requests over a WebSocket connection, but however, I've been getting this weird error that, for some reason, only happens when running my code on the aforementioned platform. Requests are converted to their raw TCP equivalent (through a custom Duplex class), sent over the connection, and forwarded to the actual HTTP server. I'm not sure of the exact cause, but below is the code that proxies the connection and my custom Duplex implementation. These are just the suspected culprits and aren't guaranteed to be the root causes of the issue.\
Code used to forward/proxy HTTP requests: (everything is written in TypeScript)
Packages used in code (all on NPM): chalk, dotenv, msgpackr, varint, ws
How often does it reproduce? Is there a required condition?
I've tried to run the same code/server on both other Linux and Windows, all on the same version of node.js I've discovered this bug on (via nvm), but to no avail. The error simply can't be replicated outside the problematic platform. Everything works as normal, and the request gets successfully proxied. After some digging around, I found out that this only happened on the 7th proxied request.
What is the expected behavior? Why is that the expected behavior?
I expected the request to get successfully proxied without issue, as shown by running the same code/server on other platforms.
What do you see instead?
The below error, with a reference to this repo's issues page:
node:internal/assert:14
throw new ERR_INTERNAL_ASSERTION(message);
^
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:393:5)
at assert (node:internal/assert:14:11)
at IncomingMessage.responseOnEnd (node:_http_client:751:5)
at IncomingMessage.emit (node:events:525:35)
at IncomingMessage.emit (node:domain:489:12)
at endReadableNT (node:internal/streams/readable:1359:12) {
code: 'ERR_INTERNAL_ASSERTION'
}
Node.js v19.1.0
Additional information
No response
The text was updated successfully, but these errors were encountered:
Version
v19.1.0 (from nix, stable 22.11)
Platform
Linux 9dbe5639fcc3 5.15.0-1030-gcp #37~20.04.1-Ubuntu SMP Mon Feb 20 04:30:57 UTC 2023 x86_64 GNU/Linux (more specifically, Replit)
Subsystem
No response
What steps will reproduce the bug?
I've been trying to proxy HTTP requests over a WebSocket connection, but however, I've been getting this weird error that, for some reason, only happens when running my code on the aforementioned platform. Requests are converted to their raw TCP equivalent (through a custom Duplex class), sent over the connection, and forwarded to the actual HTTP server. I'm not sure of the exact cause, but below is the code that proxies the connection and my custom Duplex implementation. These are just the suspected culprits and aren't guaranteed to be the root causes of the issue.\
Code used to forward/proxy HTTP requests: (everything is written in TypeScript)
Duplex implementation:
Packages used in code (all on NPM):
chalk
,dotenv
,msgpackr
,varint
,ws
How often does it reproduce? Is there a required condition?
I've tried to run the same code/server on both other Linux and Windows, all on the same version of node.js I've discovered this bug on (via nvm), but to no avail. The error simply can't be replicated outside the problematic platform. Everything works as normal, and the request gets successfully proxied. After some digging around, I found out that this only happened on the 7th proxied request.
What is the expected behavior? Why is that the expected behavior?
I expected the request to get successfully proxied without issue, as shown by running the same code/server on other platforms.
What do you see instead?
The below error, with a reference to this repo's issues page:
Additional information
No response
The text was updated successfully, but these errors were encountered: