-
Notifications
You must be signed in to change notification settings - Fork 1.8k
refactor(NODE-5675): refactor server selection and connection checkout to use abort signals for timeout management #3890
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
Changes from all commits
c2394d5
7af665f
b53ab02
f6e8da1
d4022bd
548a1c7
3b1427b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,6 +1,7 @@ | ||
import * as crypto from 'crypto'; | ||
import type { SrvRecord } from 'dns'; | ||
import * as http from 'http'; | ||
import { clearTimeout, setTimeout } from 'timers'; | ||
import * as url from 'url'; | ||
import { URL } from 'url'; | ||
|
||
|
@@ -1254,3 +1255,30 @@ export async function request( | |
req.end(); | ||
}); | ||
} | ||
|
||
/** | ||
* A custom AbortController that aborts after a specified timeout. | ||
* | ||
* If `timeout` is undefined or \<=0, the abort controller never aborts. | ||
* | ||
* This class provides two benefits over the built-in AbortSignal.timeout() method. | ||
* - This class provides a mechanism for cancelling the timeout | ||
* - This class supports infinite timeouts by interpreting a timeout of 0 as infinite. This is | ||
* consistent with existing timeout options in the Node driver (serverSelectionTimeoutMS, for example). | ||
* @internal | ||
*/ | ||
export class TimeoutController extends AbortController { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This makes sense. Do you feel it would be beneficial to also capture this behavior in the PR description or the ticket information? |
||
constructor( | ||
timeout = 0, | ||
private timeoutId = timeout > 0 ? setTimeout(() => this.abort(), timeout) : null | ||
) { | ||
super(); | ||
} | ||
|
||
clear() { | ||
if (this.timeoutId != null) { | ||
clearTimeout(this.timeoutId); | ||
} | ||
this.timeoutId = 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.
You might ask - why are we using AbortControllers and then manually consuming their signal, instead of making ConnectionPool.checkOut accept an abort signal? Really, there are a few reasons but it's primarily with the eventual state of CSOT in mind (note: everything here applies to server selection as well):
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.
I agree, considering the perspective how this piece of code relates to CSOT as a whole. What was the reasoning for not including this information in, say, the PR description so that team reviewers will be able to access it easier?
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.
Just preference. I try to answer questions that reviewers might have as they're reviewing the code in advance of anyone reviewing it. I've found the most effective way to do that is by adding comments at the places I think reviewers might have questions