-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Handle connection after connect event was emitted #1095
Conversation
It's possible for connect promise to resolve after the resolved connection has already been established, which means we miss the connect event. This can happen when Bluebird is set as the global Promise, and we connect to an ip address host for example. This fix checks to see if that's the case and invokes the connection handler directly. Thanks @luin for the recommendation. Fixes redis#977
I think we should ignore |
@luin You're right! Pushed a fix |
Thanks @alavers and @imatlopez for putting up a fix! Dealing with this bug right now and was hoping a fix would come out. Do you think we can get this merged and published soon? |
🎉 This PR is included in version 4.16.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
## [4.16.2](redis/ioredis@v4.16.1...v4.16.2) (2020-04-11) ### Bug Fixes * dismiss security alerts for dev dependencies [skip release] ([758b3f2](redis/ioredis@758b3f2)) * handle connection after connect event was emitted ([#1095](redis/ioredis#1095)) ([16a0610](redis/ioredis@16a0610)), closes [#977](redis/ioredis#977)
It's possible for connect promise to resolve after the resolved
connection has already been established, which means we miss the connect
event. This can happen when Bluebird is set as the global Promise, and
we connect to an ip address host for example. This fix checks to see if
that's the case and invokes the connection handler directly. Thanks
@luin for the recommendation.
Fixes #977