6.15.0 (2025-03-18)
The MongoDB Node.js team is pleased to announce version 6.15.0 of the mongodb
package!
Release Notes
Support for custom AWS credential providers
The driver now supports a user supplied custom AWS credentials provider for both authentication and for KMS requests when using client side encryption. The signature for the custom provider must be of () => Promise<AWSCredentials>
which matches that of the official AWS SDK provider API. Provider chains from the actual AWS SDK can also be provided, allowing users to customize any of those options.
Example for authentication with a provider chain from the AWS SDK:
import { fromNodeProviderChain } from '@aws-sdk/credential-providers';
const client = new MongoClient(process.env.MONGODB_URI, {
authMechanismProperties: {
AWS_CREDENTIAL_PROVIDER: fromNodeProviderChain()
}
});
Example for using a custom provider for KMS requests only:
import { fromNodeProviderChain } from '@aws-sdk/credential-providers';
const client = new MongoClient(process.env.MONGODB_URI, {
autoEncryption: {
keyVaultNamespace: 'keyvault.datakeys',
kmsProviders: { aws: {} },
credentialProviders: {
aws: fromNodeProviderChain()
}
}
}
Custom providers do not need to come from the AWS SDK, they just need to be an async function that returns credentials:
const client = new MongoClient(process.env.MONGODB_URI, {
authMechanismProperties: {
AWS_CREDENTIAL_PROVIDER: async () => {
return {
accessKeyId: process.env.ACCESS_KEY_ID,
secretAccessKey: process.env.SECRET_ACCESS_KEY
}
}
}
});
Fix misc unhandled rejections under special conditions
We identified an issue with our test suite that suppressed catching unhandled rejections and surfacing them to us so we can ensure the driver handles any possible rejections. Luckily only 3 cases were identified and each was under a flagged or specialized code path that may not have been in use:
- If the MongoClient was configured to use
OIDC
and anAbortSignal
was aborted on cursor at the same time the client was reauthenticating, if the reauth process was rejected it would have been unhandled. - If
timeoutMS
was used and the timeout expired before an operation reached the server selection step the operation would throw the expected timeout error but a promise representing the timeout would also raise an unhandled rejection. - If a change stream was closed while processing a change event it was possible for the "change stream is closed" error to be emitted as an error event and reject an internal promise representing fetching the "next" change.
Features
Bug Fixes
Documentation
We invite you to try the mongodb
library immediately, and report any issues to the NODE project.