Releases: mongodb/node-mongodb-native
v6.16.0
6.16.0 (2025-04-21)
The MongoDB Node.js team is pleased to announce version 6.16.0 of the mongodb package!
Release Notes
distinct commands now support an index hint
The Collection.distinct() method now supports an optional hint, which can be used to tell the server which index to use for the command:
// providing an index description
await collection.distinct('my-key', {
hint: { 'my-key': 1 }
});
// providing an index name
await collection.distinct('my-key', {
hint: 'my-key'
});This requires server 7.1+.
Driver support for servers <=4.0 deprecated
Warning
Node driver support for server 4.0 will be removed in an upcoming minor release. Reference: MongoDB Software Lifecycle Schedules.
Fix processing of multiple messages within one network data chunk
During elections, or other scenarios where the server is pushing multiple topology updates to the driver in a short period of time, a bug in the driver's socket code led to backlog of topology updates that would remain in the buffer until another heartbeat arrived from the server. This could lead to delays in the driver recovering from an election and/or an increase in MongoServerSelectionErrors.
Now, all messages in the current buffer are returned to the driver leading to faster processing times.
Huge thank you to @andreim-brd for sharing a self-contained reproduction that proved to be instrumental in the identification of the underlying issue!
FindCursor.rewind() throws documents?.clear() is not a function errors in certain scenarios
In certain scenarios where limit and batchSize are both set on a FindCursor, an internal driver optimization intended to prevent unnecessary requests to the server when the driver knows the cursor is exhausted would prevent the cursor from being rewound. This issue has been resolved.
Features
- NODE-6494: add support for
hinton distinct commands (#4487) (40d0e87) - NODE-6515: deprecate driver support for server 4.0 (#4517) (4c1a8a7)
Bug Fixes
- NODE-6630: read all messages in buffer when chunk arrives (#4512) (8c86e30)
- NODE-6878: documents.clear() throws a TypeError after cursor is rewound (#4488) (a1fffeb)
Documentation
We invite you to try the mongodb library immediately, and report any issues to the NODE project.
Contributors
Assets 4
v6.15.0
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
OIDCand anAbortSignalwas aborted on cursor at the same time the client was reauthenticating, if the reauth process was rejected it would have been unhandled. - If
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. - 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.
v6.14.2
6.14.2 (2025-03-04)
The MongoDB Node.js team is pleased to announce version 6.14.2 of the mongodb package!
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 mongodb library immediately, and report any issues to the NODE project.
v6.14.1
6.14.1 (2025-03-03)
The MongoDB Node.js team is pleased to announce version 6.14.1 of the mongodb package!
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 mongodb library immediately, and report any issues to the NODE project.
v6.14.0
6.14.0 (2025-02-28)
The MongoDB Node.js team is pleased to announce version 6.14.0 of the mongodb package!
Release Notes
Add support for $lookup on encrypted collections
Starting in the upcoming MongoDB server 8.1, the aggregation stage $lookup can now be used with clients configured for automatic encryption after upgrading to mongodb-client-encryption@>=6.3.0! 🔒 🎉
Use isUint8Array defined in the driver rather than util/types
Some 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 isUint8Array so we do not need to add an import for "util/types".
Revert @aws-sdk/credential-providers compatiblity change
In v6.13.1 we inadvertantly raised the version compatibility of @aws-sdk/credential-providers, that change has been reverted.
Features
- NODE-6676: add support for
nsTypein change stream create events (#4431) (7800067) - NODE-6773: add support for $lookup with automatic encryption (#4427) (965b21a)
Bug Fixes
- NODE-6765: FindOneAndUpdateOptions supports aggregation expressions (#4423) (421ddeb)
- NODE-6792: use isUint8Array from driver's utils instead of util/types (#4436) (dfe1fba)
- NODE-6794: revert
@aws-sdk/credential-providerspeer compatibility change (#4437) (488c407)
Documentation
We invite you to try the mongodb library immediately, and report any issues to the NODE project.
v6.13.1
6.13.1 (2025-02-20)
The MongoDB Node.js team is pleased to announce version 6.13.1 of the mongodb package!
Release Notes
Remove extraneous Promise<Document> in Collection.replaceOne return type
The return type signature of the replaceOne method no longer includes the general Promise<Document> type. Thanks to @arturmuller, the replaceOne type signature is now more accurate! 🎉
Fix writeConcern omitted when timeoutMS is provided
When timeoutMS and a write concern were provided, the writeConcern was 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 bson versions 6.10.3 and 6.10.2 into the driver.
BSON 6.10.2 fixed an issue in calculateObjectSize ignoring the size contributed by BigInt values to a BSON document. This impacted batch splitting logic in bulkWrite operations: if the actual BSON was over the size returned by calculateObjectSize the server would return an error.
Warning
BSON 6.10.3 addresses a potential data corruption risk with the use of useBigInt64 flag introduced in BSON 6.4.0, where negative Long values would be deserialized into BigInt as unsigned integers when the useBigInt64 flag was enabled. (Thanks to @rkistner for reporting this issue!)
Bug Fixes
- NODE-6407: use conversationId returned from server in saslContinue (#4368) (fbefa6b)
- NODE-6613: Update error messages when primaries go stale (#4397) (6528c8d)
- NODE-6690: Remove extraneous Document in replaceOne return type (#4383) (6c81d4e)
- NODE-6763: pass WriteConcernOptions instead on WriteConcernSettings (#4421) (26f15d7)
- NODE-6777: update BSON to 6.10.3 (#4428) (db5b9e0)
Documentation
We invite you to try the mongodb library immediately, and report any issues to the NODE project.
Contributors
Assets 4
v6.13.0
6.13.0 (2025-01-30)
The MongoDB Node.js team is pleased to announce version 6.13.0 of the mongodb package!
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!
env MONGODB_LOG_ALL=debug node server.mjsTip
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 and CommandSucceededEvents may lead to undefined behaviour.
🧪 Experimental AbortSignal support added to Find and Aggregate! 🚥
A signal argument 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 getMore operation 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 MongoClient will now close any associated cursors upon its close()-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
- NODE-5672: support standardized logging (#4387) (d1b2453)
- NODE-6258: add signal support to find and aggregate (#4364) (73def18)
- NODE-6451: retry SRV and TXT lookup for DNS timeout errors (#4375) (fd902d3)
- NODE-6633: MongoClient.close closes active cursors (#4372) (654069f)
Bug Fixes
- NODE-5225: concurrent MongoClient.close() calls each attempt to close the client (#4376) (9419af7)
- NODE-6340: OIDC reauth uses caches speculative auth result (#4379) (8b2b7fd)
Performance Improvements
- NODE-6452: Optimize CommandStartedEvent and CommandSucceededEvent constructors (#4371) (41b066b)
- NODE-6616: shortcircuit logging ejson.stringify (#4377) (c1bcf0d)
Documentation
We invite you to try the mongodb library immediately, and report any issues to the NODE project.
v6.12.0
6.12.0 (2024-12-10)
The MongoDB Node.js team is pleased to announce version 6.12.0 of the mongodb package!
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.error field when primary marked stale
We 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
- NODE-6593: add support for [email protected] (#4346) (ea8a33f)
- NODE-6605: add error message when invalidating primary (#4340) (37613f1)
Bug Fixes
- NODE-6583: upgrade to BSON v6.10.1 to remove internal unbounded type cache (#4338) (249c279)
- NODE-6600: set object mode correctly for message chunking in SizedMessageTransform (#4345) (5558573)
- NODE-6602: only wrap errors from SOCKS in network errors (#4347) (ed83f36)
Documentation
We invite you to try the mongodb library immediately, and report any issues to the NODE project.
v6.11.0
6.11.0 (2024-11-22)
The MongoDB Node.js team is pleased to announce version 6.11.0 of the mongodb package!
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,timeoutMS that 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 timeoutMS as follows:
await collection.find({}, {timeoutMS: 600_000}).toArray(); // Ensures that the find will throw a timeout error if all documents are not retrieved within 10 minutes
// Potential Stack trace if this were to time out:
// Uncaught MongoOperationTimeoutError: Timed out during socket read (600000ms)
// at Connection.readMany (mongodb/lib/cmap/connection.js:427:31)
// at async Connection.sendWire (mongodb/lib/cmap/connection.js:246:30)
// at async Connection.sendCommand (mongodb/lib/cmap/connection.js:281:24)
// at async Connection.command (mongodb/lib/cmap/connection.js:323:26)
// at async Server.command (mongodb/lib/sdam/server.js:170:29)
// at async GetMoreOperation.execute (mongodb/lib/operations/get_more.js:58:16)
// at async tryOperation (mongodb/lib/operations/execute_operation.js:203:20)
// at async executeOperation (mongodb/lib/operations/execute_operation.js:73:16)
// at async FindCursor.getMore (mongodb/lib/cursor/abstract_cursor.js:590:16)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?
timeoutMS
The main new option introduced with CSOT is the timeoutMS option. 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 timeoutMS option is specified, it will always take precedence over the following options:
socketTimeoutMSwaitQueueTimeoutMSwTimeoutMSmaxTimeMSmaxCommitTimeMS
Note, however that timeoutMS DOES NOT unconditionally override the serverSelectionTimeoutMS option.
When timeoutMS is specified, the duration of time allotted to the server selection and connection checkout portions of command execution is defined by min(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 as 0. Note also that the driver has a default value for serverSelectionTimeoutMS of 30000.
After server selection and connection checkout are complete, the time remaining bounds the execution of the remainder of the operation.
Note
Specifying timeoutMS is 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 by timeoutMS.
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.- CSFLE/QE - can take up to 2 * timeoutMS in rare error scenarios when the driver must clean up cursors used internally when fetching keys from the keyvault or listing collections.
In the AbstractCursor.toArray case and the AbstractCursor.[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 the killCursors command to close the cursor on the server.
The MongoClient.bulkWrite and autoencryption implementations use cursors under the hood and so inherit this issue.
Cursors, timeoutMS and timeoutMode
Cursors 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 the timeoutMS to 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 subsequent getMore calls MUST finish within timeoutMS or a timeout error will be thrown. Note, however that the closing of a cursor, either as part of a toArray() call or manually via the close() method resets the timeout before sending a killCursors operation to the server.
e.g.
// This will ensure that the initialization of the cursor and retrieval of all docments will occur within 1000ms, throwing an error if it exceeds this time limit
const docs = await collection.find({}, {timeoutMS: 1000}).toArray();The second, 'iteration' mode, uses timeoutMS to bound each next/hasNext/tryNext call, 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.
// Each turn of the async iterator will take up to 1000ms before it throws
for await (const doc of cappedCollection.find({}, {tailable: true, timeoutMS: 1000})) {
// process document
}Note that timeoutMode is also configurable on a per-cursor basis.
GridFS and timeoutMS
GridFS streams interact with timeoutMS in a similar manner to cursors in 'cursorLifeTime' mode in that timeoutMS bounds the entire lifetime of the stream.
In addition, GridFSBucket.find, GridFSBucket.rename and GridFSBucket.drop all support the timeoutMS option and behave in the same way as other operations.
Sessions, Transactions, timeoutMS and defaultTimeoutMS
ClientSessions have a new option: defaultTimeoutMS, which specifies the timeoutMS value to use for:
commitTransactionabortTransactionwithTransactionendSession
Note
If defaultTimeoutMS is not specified, then it will inherit the timeoutMS of the parent MongoClient.
When using ClientSession.withTransaction, the timeoutMS can be configured either in the options on the withTransaction call or inherited from the session's defaultTimeoutMS. This timeoutMS will apply to the entirety of the withTransaction callback 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 the timeoutMS at the operation level for operations making use of the explicit session inside the withTransaction callback will result in an error being thrown.
const session = client.startSession({defaultTimeoutMS: 1000});
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 timeoutMS
The ClientEncryption class now supports the timeoutMS option. If timeoutMS is provided when constructing a ClientEncryption instance, it will be used to govern the lifetime of all operations performed on instance, otherwise, it will inherit from the timeoutMS set on the MongoClient provided to the ClientEncryption constructor.
If timeoutMS is set on both the client and provided to ClientEncryption directly, the option provided to ClientEncryption takes precedence.
const encryption = new ClientEncryption(new MongoClient('localhost:27027'), { timeoutMS: 1_000 });
await encryption.createDataKey('local'); // will not take longer than 1_000ms
const encryption = new ClientEncryption(new MongoClient('localhost:27027', { timeoutMS: 1_000 }));
await encryption.createDataKey('local'); // will not take longer than 1_000ms
const encryption = new ClientEncryption(new MongoClient('localhost:27027', { timeoutMS: 5_000 }), { timeoutMS: 1_000 });
await encryption.createDataKey('local'); // will not take longer than 1_000msLimitations
At the time of writing, when using the driver's autoconnect feature alongside CSOT, the time taken for the command doing the autonnection will not be bound by the configured timeoutMS. We made this design choice because the client's connection logic handles a number of potentially long-running I/O and other setup operations including reading certificate files, DNS lookups, instantiating server monitors, and launching external processes for client encryption.
We recommend manuall...
v6.10.0
6.10.0 (2024-10-21)
The MongoDB Node.js team is pleased to announce version 6.10.0 of the mongodb package!
Release Notes
Warning
Server versions 3.6 and lower will get a compatibility error on connection and support for MONGODB-CR authentication is now also removed.
Support for new client bulkWrite API (8.0+)
A new bulk write API on the MongoClient is now supported for users on server versions 8.0 and higher.
This API is meant to replace the existing bulk write API on the Collection as it supports a bulk
write across multiple databases and collections in a single call.
Usage
Users of this API call MongoClient#bulkWrite and provide a list of bulk write models and options.
The models have a structure as follows:
Insert One
Note that when no _id field is provided in the document, the driver will generate a BSON ObjectId
automatically.
{
namespace: '<db>.<collection>',
name: 'insertOne',
document: Document
}Update One
{
namespace: '<db>.<collection>',
name: 'updateOne',
filter: Document,
update: Document | Document[],
arrayFilters?: Document[],
hint?: Document | string,
collation?: Document,
upsert: boolean
}Update Many
Note that write errors occuring with an update many model present are not retryable.
{
namespace: '<db>.<collection>',
name: 'updateMany',
filter: Document,
update: Document | Document[],
arrayFilters?: Document[],
hint?: Document | string,
collation?: Document,
upsert: boolean
}Replace One
{
namespace: '<db>.<collection>',
name: 'replaceOne',
filter: Document,
replacement: Document,
hint?: Document | string,
collation?: Document
}Delete One
{
namespace: '<db>.<collection>',
name: 'deleteOne',
filter: Document,
hint?: Document | string,
collation?: Document
}Delete Many
Note that write errors occuring with a delete many model present are not retryable.*
{
namespace: '<db>.<collection>',
name: 'deleteMany',
filter: Document,
hint?: Document | string,
collation?: Document
}Example
Below is a mixed model example of using the new API:
const client = new MongoClient(process.env.MONGODB_URI);
const models = [
{
name: 'insertOne',
namespace: 'db.authors',
document: { name: 'King' }
},
{
name: 'insertOne',
namespace: 'db.books',
document: { name: 'It' }
},
{
name: 'updateOne',
namespace: 'db.books',
filter: { name: 'it' },
update: { $set: { year: 1986 } }
}
];
const result = await client.bulkWrite(models);The bulk write specific options that can be provided to the API are as follows:
ordered: Optional boolean that indicates the bulk write as ordered. Defaults to true.verboseResults: Optional boolean to indicate to provide verbose results. Defaults to false.bypassDocumentValidation: Optional boolean to bypass document validation rules. Defaults to false.let: Optional document of parameter names and values that can be accessed using $$var. No default.
The object returned by the bulk write API is:
interface ClientBulkWriteResult {
// Whether the bulk write was acknowledged.
readonly acknowledged: boolean;
// The total number of documents inserted across all insert operations.
readonly insertedCount: number;
// The total number of documents upserted across all update operations.
readonly upsertedCount: number;
// The total number of documents matched across all update operations.
readonly matchedCount: number;
// The total number of documents modified across all update operations.
readonly modifiedCount: number;
// The total number of documents deleted across all delete operations.
readonly deletedCount: number;
// The results of each individual insert operation that was successfully performed.
// Note the keys in the map are the associated index in the models array.
readonly insertResults?: ReadonlyMap<number, ClientInsertOneResult>;
// The results of each individual update operation that was successfully performed.
// Note the keys in the map are the associated index in the models array.
readonly updateResults?: ReadonlyMap<number, ClientUpdateResult>;
// The results of each individual delete operation that was successfully performed.
// Note the keys in the map are the associated index in the models array.
readonly deleteResults?: ReadonlyMap<number, ClientDeleteResult>;
}Error Handling
Server side errors encountered during a bulk write will throw a MongoClientBulkWriteError. This error
has the following properties:
writeConcernErrors: Ann array of documents for each write concern error that occurred.writeErrors: A map of index pointing at the models provided and the individual write error.partialResult: The client bulk write result at the point where the error was thrown.
Schema assertion support
interface Book {
name: string;
authorName: string;
}
interface Author {
name: string;
}
type MongoDBSchemas = {
'db.books': Book;
'db.authors': Author;
}
const model: ClientBulkWriteModel<MongoDBSchemas> = {
namespace: 'db.books'
name: 'insertOne',
document: { title: 'Practical MongoDB Aggregations', authorName: 3 }
// error `authorName` cannot be number
};Notice how authorName is type checked against the Book type because namespace is set to "db.books".
Allow SRV hostnames with fewer than three . separated parts
In an effort to make internal networking solutions easier to use like deployments using kubernetes, the client now accepts SRV hostname strings with one or two . separated parts.
await new MongoClient('mongodb+srv://mongodb.local').connect();For security reasons, the returned addresses of SRV strings with less than three parts must end with the entire SRV hostname and contain at least one additional domain level. This is because this added validation ensures that the returned address(es) are from a known host. In future releases, we plan on extending this validation to SRV strings with three or more parts, as well.
// Example 1: Validation fails since the returned address doesn't end with the entire SRV hostname
'mongodb+srv://mySite.com' => 'myEvilSite.com'
// Example 2: Validation fails since the returned address is identical to the SRV hostname
'mongodb+srv://mySite.com' => 'mySite.com'
// Example 3: Validation passes since the returned address ends with the entire SRV hostname and contains an additional domain level
'mongodb+srv://mySite.com' => 'cluster_1.mySite.com' Explain now supports maxTimeMS
Driver CRUD commands can be explained by providing the explain option:
collection.find({}).explain('queryPlanner'); // using the fluent cursor API
collection.deleteMany({}, { explain: 'queryPlanner' }); // as an optionHowever, if maxTimeMS was provided, the maxTimeMS value was applied to the command to explain, and consequently the server could take more than maxTimeMS to respond.
Now, maxTimeMS can be specified as a new option for explain commands:
collection.find({}).explain({ verbosity: 'queryPlanner', maxTimeMS: 2000 }); // using the fluent cursor API
collection.deleteMany({}, {
explain: {
verbosity: 'queryPlanner',
maxTimeMS: 2000
}
); // as an optionIf a top-level maxTimeMS option is provided in addition to the explain maxTimeMS, the explain-specific maxTimeMS is applied to the explain command, and the top-level maxTimeMS is applied to the explained command:
collection.deleteMany({}, {
maxTimeMS: 1000,
explain: {
verbosity: 'queryPlanner',
maxTimeMS: 2000
}
);
// the actual command that gets sent to the server looks like:
{
explain: { delete: <collection name>, ..., maxTimeMS: 1000 },
verbosity: 'queryPlanner',
maxTimeMS: 2000
}Find and Aggregate Explain in Options is Deprecated
Note
Specifying explain for cursors in the operation's options is deprecated in favor of the .explain() methods on cursors:
collection.find({}, { explain: true })
// -> collection.find({}).explain()
collection.aggregate([], { explain: true })
// -> collection.aggregate([]).explain()
db.find([], { explain: true })
// -> db.find([]).explain()Fixed writeConcern.w set to 0 unacknowledged write protocol trigger
The driver now correctly handles w=0 writes as 'fire-and-forget' messages, where the server does not reply and the driver does not wait for a response. This change eliminates the possibility of encountering certain rare protocol format, BSON type, or network errors that could previously arise during server replies. As a result, w=0 operations now involve less I/O, specifically no socket read.
In addition, when command monitoring is enabled, the reply field of a CommandSucceededEvent of an unacknowledged write will always be { ok: 1 }.
Fixed indefinite hang bug for high write load scenarios
When performing large and many write operations, the driver will likely encounter buffering at the socket layer. The logic that waited until buffered writes were complete would mistakenly drop 'data' (reading from the socket), causing the driver to hang indefinitely or until a socket timeout. Using pausing and resuming mechanisms exposed by Node streams we have eliminated the possibility for data events to go unhandled.
Shout out to @hunkydoryrepair for debugging and finding this issue!
Fixed change stream infinite resume
Before this fix, when change streams would fail to establish a cursor on the server, the driver would infinitely attempt to resume the change stream. Now, when the aggregate to establish the change stream fails, the driver will throw an error and clos the change stream.
