Skip to content

feat(NODE-6245): add keepAliveInitialDelay config #4510

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 5 commits into
base: main
Choose a base branch
from
Open

Conversation

durran
Copy link
Member

@durran durran commented Apr 16, 2025

Description

Brings back the keepAliveInitialDelay option.

What is changing?

  • Adds keepAliveInitialDelay as an option to pass to the socket.
  • Defaults now to 120 seconds instead of 300
Is there new documentation needed for these changes?

Yes, driver docs.

What is the motivation for this change?

NODE-6245

Release Highlight

keepAliveInitialDelay may now be configured at the MongoClient level

When not present will default to 120 seconds. The option value must be specified in milliseconds.

import { MongoClient } from 'mongodb';

const client = new MongoClient(process.env.MONGODB_URI, { keepAliveInitialDelay: 100000 });

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

@durran durran marked this pull request as ready for review April 16, 2025 18:14
@durran durran requested a review from a team as a code owner April 16, 2025 18:14
});
});

context('when the value is negative', function () {
Copy link
Contributor

@dariakp dariakp Apr 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The AC on the ticket says:

allow it to be a pass-through (no validation)

do we need to revisit this requirement as a team?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any mongo client option has to be added to the connection string options, which is going to validate since the number is set as a uint. A negative number for this setting isn't valid anyways, so there's really no reason to set the type in the connection string module as something that can be invalid.

@@ -115,7 +115,11 @@ export type SupportedTLSSocketOptions = Pick<

/** @public */
export type SupportedSocketOptions = Pick<
TcpNetConnectOpts & { autoSelectFamily?: boolean; autoSelectFamilyAttemptTimeout?: number },
TcpNetConnectOpts & {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also have AC to add API docs and mongo manual docs for the new option - is that something we want to revisit?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll update the API docs. Mongo manual I flagged on the ticket with doc changes needed.

@durran durran requested a review from dariakp April 17, 2025 12:05
@dariakp dariakp added the Primary Review In Review with primary reviewer, not yet ready for team's eyes label Apr 17, 2025
@dariakp dariakp requested a review from nbbeeken April 17, 2025 14:51
@nbbeeken
Copy link
Contributor

Capturing from our meeting: we want to get the keepAlive related options into the "options" argument we pass into tls/net .connect() and move off of calling the setKeepAlive and noDelay functions so that we are just passing Node.js configurations through to Node.js without our own validation or opinionated handling.

KeepAlive will still always be enabled and not configurable.

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.

4 participants