[Snyk] Upgrade mongodb from 6.2.0 to 6.15.0 #101
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Snyk has created this PR to upgrade mongodb from 6.2.0 to 6.15.0. See this package in npm: mongodb See this project in Snyk: https://app.snyk.io/org/lydiamoon7/project/db315a82-4a35-495f-9f45-8c58e365dfea?utm_source=github&utm_medium=referral&page=upgrade-pr
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Snyk has created this PR to upgrade mongodb from 6.2.0 to 6.15.0.
ℹ️ Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.
The recommended version is 218 versions ahead of your current version.
The recommended version was released a month ago.
Release notes
Package name: mongodb
6.15.0 (2025-03-18)
The MongoDB Node.js team is pleased to announce version 6.15.0 of the
mongodbpackage!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:
const client = new MongoClient(process.env.MONGODB_URI, {
authMechanismProperties: {
AWS_CREDENTIAL_PROVIDER: fromNodeProviderChain()
}
});
Example for using a custom provider for KMS requests only:
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:
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:
OIDCand anAbortSignalwas aborted on cursor at the same time the client was reauthenticating, if the reauth process was rejected it would have been unhandled.timeoutMSwas 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.Features
Bug Fixes
Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.14.2 (2025-03-04)
The MongoDB Node.js team is pleased to announce version 6.14.2 of the
mongodbpackage!Release Notes
KMS Requests can cause unhandled rejection
When using explicit encryption or automatic encryption, the driver makes requests to a Key Management System when to fetch key encryption keys. The driver supports connecting to a KMS provider through a Socks5 proxy. However, the socket used for the socks5 proxy was created in all circumstances, regardless of proxy configuration. This leads to unhandled rejection errors when closing the socket the driver attempts to clean up the unused socket.
With the changes in this release, the socket is only created if a proxy is configured and the any promises created for the proxy are properly handled.
Bug Fixes
Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.14.1 (2025-03-03)
The MongoDB Node.js team is pleased to announce version 6.14.1 of the
mongodbpackage!Release Notes
Fixed occasional OIDC reauthentication failure
Error code 391 is intended to make the driver internally reauthenticate the connection to the server, however, occasionally this was being raised to the user. This was due to a bug in setting the cached access token on newly created connections.
Bug Fixes
Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.14.0 (2025-02-28)
The MongoDB Node.js team is pleased to announce version 6.14.0 of the
mongodbpackage!Release Notes
Add support for $lookup on encrypted collections
Starting in the upcoming MongoDB server 8.1, the aggregation stage
$lookupcan now be used with clients configured for automatic encryption after upgrading tomongodb-client-encryption@>=6.3.0! 🔒 🎉Use
isUint8Arraydefined in the driver rather thanutil/typesSome users of bundlers for next.js and our very own mongosh noticed a new import from "util/types" that would need to be supported in environments that don't have that module. We already have an internal implementation of
isUint8Arrayso we do not need to add an import for "util/types".Revert
@ aws-sdk/credential-providerscompatiblity changeIn v6.13.1 we inadvertantly raised the version compatibility of
@ aws-sdk/credential-providers, that change has been reverted.Features
nsTypein change stream create events (#4431) (7800067)Bug Fixes
@ aws-sdk/credential-providerspeer compatibility change (#4437) (488c407)Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.13.1 (2025-02-20)
The MongoDB Node.js team is pleased to announce version 6.13.1 of the
mongodbpackage!Release Notes
Remove extraneous
Promise<Document>inCollection.replaceOnereturn typeThe return type signature of the
replaceOnemethod no longer includes the generalPromise<Document>type. Thanks to @ arturmuller, thereplaceOnetype signature is now more accurate! 🎉Fix writeConcern omitted when timeoutMS is provided
When
timeoutMSand a write concern were provided, thewriteConcernwas incorrectly omitted from the final command executed by the driver.Thanks @ stepanho for contributing the fix!
Update BSON version requirement to 6.10.3
This pulls in fixes made in
bsonversions 6.10.3 and 6.10.2 into the driver.BSON 6.10.2 fixed an issue in
calculateObjectSizeignoring the size contributed byBigIntvalues to a BSON document. This impacted batch splitting logic inbulkWriteoperations: if the actual BSON was over the size returned bycalculateObjectSizethe server would return an error.Warning
BSON 6.10.3 addresses a potential data corruption risk with the use of
useBigInt64flag introduced in BSON 6.4.0, where negativeLongvalues would be deserialized intoBigIntas unsigned integers when theuseBigInt64flag was enabled. (Thanks to @ rkistner for reporting this issue!)Bug Fixes
Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.13.0 (2025-01-30)
The MongoDB Node.js team is pleased to announce version 6.13.0 of the
mongodbpackage!Release Notes
MongoDB Standardized Logging 📝
The driver's standardized logger is now available! The primary goal of our driver's logger is to enable insight into database operations without code changes so enabling and configuring the logger are primarily done through our environment variables.
TL;DR Show me the logs!
Tip
If you are a CLI app developer (or otherwise take great care of your std outputs): The client options constructor argument takes precedence over environment variables, permitting you to disable or otherwise customize the logger so your app does not automatically respond to the current environment.
Check out the in-depth logging docs here: https://www.mongodb.com/docs/drivers/node/current/fundamentals/logging/
🚀 Improved command monitoring performance
Previously, when command monitoring was enabled, the driver would make deep copies of command and reply objects, which have the potential to be very large documents. These copies have been eliminated, providing a speed and memory efficiency bump to command monitoring.
Warning
Since we no longer make deep copies of commands/replies in Command Monitoring Events, directly modifying the command/reply objects on
CommandStartedEvents andCommandSucceededEvents may lead to undefined behaviour.🧪 Experimental AbortSignal support added to Find and Aggregate! 🚥
A
signalargument can now be passed to the following APIs:collection.find()&collection.findOne()collection.aggregate()&collection.countDocuments()In order to support field level encryption properly, also:
db.listCollections()db.command()When aborted, the signal will interrupt the execution of each of each of these APIs. For the cursor-based APIs, this will be observed when attempting to consume from the cursor via toArray(), next(), for-await, etc.
There is a known limitation: aborting a signal closes a perfectly healthy connection which can cause unnecessary connection reestablishment so we're releasing this as experimental for evaluation in use cases that can tolerate the shortcoming.
DNS SRV & TXT look up timeouts are retried
To mitigate the potentially transient DNS timeout error, the driver now catches and retries the DNS lookups upon resolving a
mongodb+srv://style connection string.MongoClient.close now closes any outstanding cursors
Previously, cursors could somewhat live beyond the client they came from. What this meant was that depending on timing you would learn of the client's (and by proxy, the cursor's) demise via an assertion that the associated session had expired. This only occurred if your cursor needed to use the session, which only happens when it is attempting to run a
getMoreoperation to obtain another batch of documents.Practically speaking a cursor that lives beyond a client is an exception waiting to happen, the connection pools are closed, the sessions are ended, last call has been served 🍻, it is only a matter of timing and event firing until the cursor learns of its fate and informs you by throwing an error via whatever API is being used (
.toArray(),for-await,.next()).To make the expected state of cursors clearer in this scenario the
MongoClientwill now close any associated cursors upon itsclose()-ing reducing the risk of leaving behind server-side resources.MongoClient.close() can be called concurrently
In the past, concurrent calls to
MongoClient.close()had poorly defined behavior depending on the exact timing of the second (or more) calls to close(). In some cases, this could also throw errors.With these changes, MongoClient.close() can be called concurrently safely and always returns the same promise.
Note
This is intended as a correctness fix - we don't recommend calling MongoClient.close() concurrently if it can be avoided.
MONGODB-OIDC now properly reauthenticates in speculative auth scenarios
When using MONGODB-OIDC authentication, if the initial handshake contained speculative authentication, the driver would not properly reauthenticate when the server would raise 391 errors. This is now fixed.
Features
Bug Fixes
Performance Improvements
Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.12.0 (2024-12-10)
The MongoDB Node.js team is pleased to announce version 6.12.0 of the
mongodbpackage!Release Notes
[email protected] is now supported for zstd compression
The new @ mongodb-js/[email protected] release can now be used with the driver for zstd compression.
Populate
ServerDescription.errorfield when primary marked staleWe now attach an error to the newly created ServerDescription object when marking a primary as stale. This helps with debugging SDAM issues when monitoring SDAM events.
BSON upgraded to v6.10.1
See: https://github.com/mongodb/js-bson/releases/tag/v6.10.1
Socket read stream set to object mode
Socket data was being read with a stream set to buffer mode when it should be set to object mode to prevent inaccurate data chunking, which may have caused message parsing errors in rare cases.
SOCKS5: MongoNetworkError wrap fix
If the driver encounters an error while connecting to a socks5 proxy, the driver wraps the socks5 error in a MongoNetworkError. In some circumstances, this resulted in the driver wrapping MongoNetworkErrors inside MongoNetworkErrors.
The driver no longer double wraps errors in MongoNetworkErrors.
Features
Bug Fixes
Documentation
We invite you to try the
mongodblibrary immediately, and report any issues to the NODE project.6.11.0 (2024-11-22)
The MongoDB Node.js team is pleased to announce version 6.11.0 of the
mongodbpackage!Release Notes
Client Side Operations Timeout (CSOT)
We've been working hard to try to simplify how setting timeouts works in the driver and are excited to finally put Client Side Operation Timeouts (CSOT) in your hands! We're looking forward to hearing your feedback on this new feature during its trial period in the driver, so feel free to file Improvements, Questions or Bug reports on our Jira Project or leave comments on this community forum thread: Node.js Driver 6.11 Forum Discussion!
CSOT is the common drivers solution for timing out the execution of an operation at the different stages of an operation's lifetime. At its simplest, CSOT allows you to specify one option,
timeoutMSthat determines when the driver will interrupt an operation and return a timeout error.For example, when executing a potentially long-running query, you would specify
timeoutMSas follows:Warning
This feature is experimental and subject to change at any time. We do not recommend using this feature in production applications until it is stable.
What's new?
timeoutMSThe main new option introduced with CSOT is the
timeoutMSoption. This option can be applied directly as a client option, as well as at the database, collection, session, transaction and operation layers, following the same inheritance behaviours as other driver options.When the
timeoutMSoption is specified, it will always take precedence over the following options:socketTimeoutMSwaitQueueTimeoutMSwTimeoutMSmaxTimeMSmaxCommitTimeMSNote, however that
timeoutMSDOES NOT unconditionally override theserverSelectionTimeoutMSoption.When
timeoutMSis specified, the duration of time allotted to the server selection and connection checkout portions of command execution is defined bymin(serverSelectionTimeoutMS, timeoutMS)if both are>0. A zero value for either timeout value represents an infinite timeout. A finite timeout will always be used unless both timeouts are specified as0. Note also that the driver has a default value forserverSelectionTimeoutMSof30000.After server selection and connection checkout are complete, the time remaining bounds the execution of the remainder of the operation.
Note
Specifying
timeoutMSis not a hard guarantee that an operation will take exactly the duration specified. In the circumstances identified below, the driver's internal cleanup logic can result in an operation exceeding the duration specified bytimeoutMS.AbstractCursor.toArray()- can take up to2 * timeoutMSin'cursorLifetimeMode'and(n+1) * timeoutMSwhen returning n batches in'iteration'modeAbstractCursor.[Symbol.asyncIterator]()- can take up to2 * timeoutMSin'cursorLifetimeMode'and (n+1)*timeoutMSwhen returning n batches in'iteration'modeMongoClient.bulkWrite()- can take up to 2 * timeoutMS in error scenarios when the driver must clean up cursors used internally.In the
AbstractCursor.toArraycase and theAbstractCursor.[Symbol.asyncIterator]case, this occurs as these methods close the cursor when they finish returning their documents. As detailed in the following section, this results in a refreshing of the timeout before sending thekillCursorscommand to close the cursor on the server.The
MongoClient.bulkWriteand autoencryption implementations use cursors under the hood and so inherit this issue.Cursors,
timeoutMSandtimeoutModeCursors require special handling with the new timout paradigm introduced here. Cursors can be configured to interact with CSOT in two ways.
The first,
'cursorLifetime'mode, uses thetimeoutMSto bound the entire lifetime of a cursor and is the default timeout mode for non-tailable cursors (find, aggregate*, listCollections, etc.). This means that the initialization of the cursor and all subsequentgetMorecalls MUST finish withintimeoutMSor a timeout error will be thrown. Note, however that the closing of a cursor, either as part of atoArray()call or manually via theclose()method resets the timeout before sending akillCursorsoperation to the server.e.g.
The second,
'iteration'mode, usestimeoutMSto bound eachnext/hasNext/tryNextcall, refreshing the timeout after each call completes. This is the default mode for all tailable cursors (tailable find cursors on capped collections, change streams, etc.). e.g.Note that
timeoutModeis also configurable on a per-cursor basis.GridFS and
timeoutMSGridFS streams interact with
timeoutMSin a similar manner to cursors in'cursorLifeTime'mode in thattimeoutMSbounds the entire lifetime of the stream.In addition,
GridFSBucket.find,GridFSBucket.renameandGridFSBucket.dropall support thetimeoutMSoption and behave in the same way as other operations.Sessions, Transactions,
timeoutMSanddefaultTimeoutMSClientSessions have a new option:
defaultTimeoutMS, which specifies thetimeoutMSvalue to use for:commitTransactionabortTransactionwithTransactionendSessionNote
If
defaultTimeoutMSis not specified, then it will inherit thetimeoutMSof the parentMongoClient.When using
ClientSession.withTransaction, thetimeoutMScan be configured either in the options on thewithTransactioncall or inherited from the session'sdefaultTimeoutMS. ThistimeoutMSwill apply to the entirety of thewithTransactioncallback provided that the session is correctly passed into each database operation. If the session is not passed into the operation, it will not respect the configured timeout. Also be aware that trying to override thetimeoutMSat the operation level for operations making use of the explicit session inside thewithTransactioncallback will result in an error being thrown.const coll = client.db('db').collection('coll');
// ❌ Incorrect; will throw an error
await session.withTransaction(async function(session) {
await coll.insertOne({x:1}, { session, timeoutMS: 600 });
})
// ❌ Incorrect; will not respect timeoutMS configured on session
await session.withTransaction(async function(session) {
await coll.insertOne({x:1}, {});
})
ClientEncryption and
timeoutMSThe
ClientEncryptionclass now supports thetimeoutMSoption. IftimeoutMSis provided when constructing aClientEncryptioninstance, it will be used to govern the lifetime of all operations performed on instance, otherwise, it will inherit from thetimeoutMSset on theMongoClientprovided to theClientEncryptionconstructor.If
timeoutMSis set on both the client and provided to ClientEncryption directly, the option provided toClientEncryptiontakes precedence.