fix(client): Avoids infinite promise-chaining when socket's creation fails - #2295
Merged
Conversation
JonasFaure
marked this pull request as ready for review
October 17, 2022 08:58
Contributor
|
@JonasFaure nice one! sorry for the long delay, I was on vacation... I'll release a version with this fix next week :) |
Codecov ReportBase: 95.85% // Head: 95.85% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #2295 +/- ##
=======================================
Coverage 95.85% 95.85%
=======================================
Files 433 433
Lines 4001 4004 +3
Branches 451 451
=======================================
+ Hits 3835 3838 +3
Misses 102 102
Partials 64 64
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
florian-schunk
pushed a commit
to florian-schunk/node-redis
that referenced
this pull request
Jun 18, 2025
…fails (redis#2295) * fix(client): timeout issues during tests * fix(client): avoiding infinite Promise chaining while socket creation fails * fix(client): Added missing semicolons * clean test Co-authored-by: leibale <leibale1998@gmail.com>
trentm
added a commit
to trentm/opentelemetry-js-contrib
that referenced
this pull request
Jun 26, 2025
In redis@4.4.0 and earlier versions of redis v4, client.disconnect()
will throw if the connect failed. That broke the "with empty string for
client URL, ..." test case, at least on macOS:
npm run test:docker:run
RUN_REDIS_TESTS=1 npm t
I cannot explain why this is not failing in CI. Perhaps something
platform specific? This is related to socket handling in the redis
client. I believe the relevant change in node-redis was:
redis/node-redis#2295
which was part of `@redis/client@1.3.1` which was included in
`redis@4.4.0`.
trentm
added a commit
to open-telemetry/opentelemetry-js-contrib
that referenced
this pull request
Jun 27, 2025
…#2914) In redis@4.4.0 and earlier versions of redis v4, client.disconnect() will throw if the connect failed. That broke the "with empty string for client URL, ..." test case, at least on macOS: npm run test:docker:run RUN_REDIS_TESTS=1 npm t I cannot explain why this is not failing in CI. Perhaps something platform specific? This is related to socket handling in the redis client. I believe the relevant change in node-redis was: redis/node-redis#2295 which was part of `@redis/client@1.3.1` which was included in `redis@4.4.0`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This change prevents a memory leak when a Redis client tries to connect to an unavailable host. This is achieve by switching from a recursive to an iterative approach.
When a Redis instance fails, our clients slowly build up memory until they get killed.
#2134
First, I had to slightly change the tests' implementation to work around timeout issues when running the tests, ie : specifying a timeout using the connectTimeout argument & giving up mocking time by specifying a very small retry delay. This commit should preferably be reverted if someone who manages to run tests locally can validate my implementation with the previous implementation for those tests 🤷
Second, I swapped the recursive call to
connectfor a do{}while loop and leverage the#this.isReadyproperty as the exit condition.Checklist
npm testpass with this change (including linting)?