-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
pool.end() resolves before the last pool.query() #3254
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
base: master
Are you sure you want to change the base?
Conversation
45d62d0
to
009acb9
Compare
Hey - this is awesome, thank you! Sorry for the delay - I'm in the mountains in colorado until Monday so i'm a bit slow to respond. Will be a lot more avail when I get home...but thanks so much for fixing/improving this. been a long-standing little bug...nice to get it taken care of! ❤️ |
Hi! I should add some corrections though, now two other tests seem not passing so I will fix it |
Because when you don't pass a callback to .end() it always returns a promise
0d7da49
to
5e91617
Compare
Howdy - looks like one of the tests for idle timeout still isn't passing - you still lookin' into that? |
Yeah, I am trying to figure out what's wrong with that |
I believe the idle timeout is failing due to a new data race caused by this fix. We now emit on remove when client ends: const context = this
client.end(() => {
context.emit('remove', client)
...
}) but the client may not end right away. Our test releases both clients and immediately sets up an "on remove" listener called Log:
I am not sure of the exact fix at the moment, but I think we need a way to wait for client release to finish. |
waiting will not work because we are trying to catch the remove event that will fix in 10ms after the attempted fix of counting clients will not work consistently because the order in which in #3461 i check for |
@hjr3 Hi! Thanks for information, I will take a look |
Here is the link to the issue: 2163