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

fix(NODE-6412): read stale response from previously timed out connection #4273

Merged
merged 1 commit into from
Oct 11, 2024

Conversation

nbbeeken
Copy link
Contributor

Description

What is changing?

  • Close a connection that has been timed out
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

  • Ran npm run check:lint script
  • Self-review completed using the steps outlined here
  • PR title follows the correct format: type(NODE-xxxx)[!]: description
    • Example: feat(NODE-1234)!: rewriting everything in coffeescript
  • Changes are covered by tests
  • New TODOs have a related JIRA ticket

@nbbeeken nbbeeken force-pushed the NODE-6412-socket-timeout-v2 branch from a56bdd7 to efbed5c Compare October 10, 2024 20:40
@nbbeeken nbbeeken marked this pull request as ready for review October 11, 2024 18:57
@W-A-James W-A-James self-assigned this Oct 11, 2024
@W-A-James W-A-James added the Primary Review In Review with primary reviewer, not yet ready for team's eyes label Oct 11, 2024
@W-A-James W-A-James self-requested a review October 11, 2024 20:28
`Timed out during socket read (${readError.duration}ms)`
);
this.dataEvents = null;
Copy link
Contributor

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?

Copy link
Contributor

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.

@W-A-James W-A-James merged commit c0d6ec9 into NODE-6090 Oct 11, 2024
27 checks passed
@W-A-James W-A-James deleted the NODE-6412-socket-timeout-v2 branch October 11, 2024 20:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Primary Review In Review with primary reviewer, not yet ready for team's eyes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants