Skip to content

fix(NODE-6864): socket errors are not always converted to MongoNetworkErrors #4473

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

nbbeeken
Copy link
Contributor

Description

What is changing?

  • Ensure socket errors are converted
  • Do not squash error in finally block
Is there new documentation needed for these changes?

No

What is the motivation for this change?

Networking errors are handled specially for retry/resume logic, if we fail to wrap them in our Network error type we won't retry them.

Release Highlight

Network errors could have been left unwrapped in a MongoNetworkError

If the timing was perfectly unlucky a socket error event could store a plain Node.js error (like read ECONNRESET) on the connection class which would then be thrown unwrapped when cleaning up the failed socket read. This only was reproducible when the mongod node was killed with SIGKILL allowing for no time for a graceful socket shutdown.

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-6858-errors branch 3 times, most recently from 73db3ae to 7170418 Compare March 18, 2025 15:22
@nbbeeken nbbeeken force-pushed the NODE-6858-errors branch 2 times, most recently from 2d85944 to b868d0b Compare April 18, 2025 20:03
@nbbeeken nbbeeken marked this pull request as ready for review April 18, 2025 20:03
@nbbeeken nbbeeken requested a review from a team as a code owner April 18, 2025 20:03
@baileympearson baileympearson self-assigned this Apr 22, 2025
@baileympearson baileympearson added the Primary Review In Review with primary reviewer, not yet ready for team's eyes label Apr 22, 2025
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