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
OS & version: Debian bullseye (we're using the node:18.4.0-bullseye docker image)
At scale, when the event loop is incredibly busy and/or blocked by larger sync tasks, timeouts can fire when the underlying event has occurred at a lower level.
One example of this is the connect timeout. Although the underlying socket connects very fast, the setTimeout that aborts the request fires before the I/O phase of the event loop has a chance to let the request know the connection was actually established.
Actual behavior
Request is aborted with Timeout awaiting 'connect' for 50ms
Expected behavior
Connection is successfully established
Code to reproduce
No easy way to produce. We started observing this at scale.
And here's a timeline of the Timeout awaiting 'connect' for XYZms errors from patching:
I understand we can go either way here. Ideally we wouldn't have to go through the event loop and could just ask the underlying socket "hey, are you connected" before aborting, but alas.
Checklist
I have read the documentation.
I have tried my code with the latest version of Node.js and Got.
The text was updated successfully, but these errors were encountered:
Describe the bug
node:18.4.0-bullseye
docker image)At scale, when the event loop is incredibly busy and/or blocked by larger sync tasks, timeouts can fire when the underlying event has occurred at a lower level.
One example of this is the
connect
timeout. Although the underlying socket connects very fast, thesetTimeout
that aborts the request fires before the I/O phase of the event loop has a chance to let the request know the connection was actually established.Actual behavior
Request is aborted with
Timeout awaiting 'connect' for 50ms
Expected behavior
Connection is successfully established
Code to reproduce
No easy way to produce. We started observing this at scale.
Here's the patch we've applied locally: main...thegedge:got:main
And here's a timeline of the
Timeout awaiting 'connect' for XYZms
errors from patching:I understand we can go either way here. Ideally we wouldn't have to go through the event loop and could just ask the underlying socket "hey, are you connected" before aborting, but alas.
Checklist
The text was updated successfully, but these errors were encountered: