Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connect timeout fired even though underlying socket is actually connected #2248

Open
2 tasks done
thegedge opened this issue Apr 6, 2023 · 0 comments
Open
2 tasks done

Comments

@thegedge
Copy link

thegedge commented Apr 6, 2023

Describe the bug

  • Node.js version: 18.4.0
  • 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.

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:

timeline showing 1 connect timeout every minute and a deploy that eliminated these events

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant