-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
fix(NODE-6412): read stale response from previously timed out connection #4273
Conversation
3591368
to
a645d9f
Compare
a56bdd7
to
efbed5c
Compare
`Timed out during socket read (${readError.duration}ms)` | ||
); | ||
this.dataEvents = null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this pretty much drop all packets that have been received but not read?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Paraphrasing response from Slack
No, I am setting it to null because the iterator has already thrown the error, connection.cleanup will call
dataEvents.throw(error)
if it exists, which it has already done because it was the one that threw
. This is just preventing us from doing the work twice.
Typically errors come from the socket, so dataEvents.throw(e) is how you get the for-await loop to "unblock"
. It's like you're inserting the error into the iterator, this new code path is coming out of the iterator, and entering clean up, so needs a new "null it out" line of code.
Description
What is changing?
Is there new documentation needed for these changes?
No
What is the motivation for this change?
If the connection is not closed it will go back into the pool and a subsequent operation will read the reply to the previous operation
Double check the following
npm run check:lint
scripttype(NODE-xxxx)[!]: description
feat(NODE-1234)!: rewriting everything in coffeescript