[Snyk] Upgrade mongodb from 6.9.0 to 6.10.0

[skanda890]

Snyk has created this PR to upgrade mongodb from 6.9.0 to 6.10.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 11 versions ahead of your current version.

• The recommended version was released on 21 days ago.

Release notes

Package name: mongodb

• 6.10.0 - 2024-10-21
  

  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 option

  However, 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 option

  If 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.

  ClientSession.commitTransaction() no longer unconditionally overrides write concern

  Prior to this change, ClientSession.commitTransaction() would always override any previously configured writeConcern on the initial attempt. This overriding behaviour now only applies to internal and user-initiated retries of ClientSession.commitTransaction() for a given transaction.

  Features

  • NODE-5838: remove support for server 3.6 (#4182) (7b71e1f)
  • NODE-6289: allow valid srv hostnames with less than 3 parts (#4197) (3d5bd51)
  • NODE-6329: client bulk write happy path (#4206) (3d3da40)
  • NODE-6337: implement client bulk write batching (#4248) (d56e235)
  • NODE-6338: implement client bulk write error handling (#4262) (8def42d)
  • NODE-6342: support maxTimeMS for explain commands (#4207) (20396e1)
  • NODE-6350: add typescript support to client bulkWrite API (#4257) (30c61f2)
  • NODE-6409: new errors for unacknowledged bulk writes (#4276) (7fde8dd)
  • NODE-6419: deprecate explain options API for find and aggregate (#4271) (a473de9)

  Bug Fixes

  • NODE-6060: set fire-and-forget protocol when writeConcern is w: 0 (#4219) (643a875)
  • NODE-6394: data events missed while awaiting drain (#4249) (3f9d243)
  • NODE-6418: change stream resumes infinitely after failed aggregates (#4267) (6ecf198)
  • NODE-6436: only force majority write concern on commitTransaction retry (#4284) (a7d1d43)

  Documentation

  • Reference
  • API
  • Changelog

  We invite you to try the mongodb library immediately, and report any issues to the NODE project.

• 6.10.0-dev.20241112.sha.48ed47ec - 2024-11-12
• 6.10.0-dev.20241109.sha.ed25d561 - 2024-11-09
• 6.10.0-dev.20241108.sha.fd7acde6 - 2024-11-08
• 6.10.0-dev.20241107.sha.e5582ed7 - 2024-11-07
• 6.10.0-dev.20241106.sha.dc3fe957 - 2024-11-06
• 6.10.0-dev.20241102.sha.2f3fb466 - 2024-11-02
• 6.10.0-dev.20241101.sha.5e6638a2 - 2024-11-01
• 6.10.0-dev.20241031.sha.f62c45d2 - 2024-10-31
• 6.10.0-dev.20241024.sha.5c4355ad - 2024-10-24
• 6.10.0-dev.20241022.sha.678e9322 - 2024-10-22
• 6.9.0 - 2024-09-12
  

  6.9.0 (2024-09-06)

  The MongoDB Node.js team is pleased to announce version 6.9.0 of the mongodb package!

  Release Notes

  Driver support of upcoming MongoDB server release

  Increased the driver's max supported Wire Protocol version and server version in preparation for the upcoming release of MongoDB 8.0.

  MongoDB 3.6 server support deprecated

  Warning

  Support for 3.6 servers is deprecated and will be removed in a future version.

  Support for explicit resource management

  The driver now natively supports explicit resource management for MongoClient, ClientSession, ChangeStreams and cursors. Additionally, on compatible Node.js versions, explicit resource management can be used with cursor.stream() and the GridFSDownloadStream, since these classes inherit resource management from Node.js' readable streams.

  This feature is experimental and subject to changes at any time. This feature will remain experimental until the proposal has reached stage 4 and Node.js declares its implementation of async disposable resources as stable.

  To use explicit resource management with the Node driver, you must:

  • Use Typescript 5.2 or greater (or another bundler that supports resource management)
  • Enable tslib polyfills for your application
  • Either use a compatible Node.js version or polyfill Symbol.asyncDispose (see the TS 5.2 release announcement for more information).

  Explicit resource management is a feature that ensures that resources' disposal methods are always called when the resources' scope is exited. For driver resources, explicit resource management guarantees that the resources' corresponding close method is called when the resource goes out of scope.

  // before:
  {
  try {
  const client = MongoClient.connect('<uri>');
  try {
  const session = client.startSession();
  const cursor = client.db('my-db').collection("my-collection").find({}, { session });
  try {
  const doc = await cursor.next();
  } finally {
  await cursor.close();
  }
  } finally {
  await session.endSession();
  }
  } finally {
  await client.close();
  }
  }

  // with explicit resource management:
  {
  await using client = MongoClient.connect('<uri>');

  await using session = client.startSession();
  await using cursor = client.db('my-db').collection('my-collection').find({}, { session });

  const doc = await cursor.next();
  }
  // outside of scope, the cursor, session and mongo client will be cleaned up automatically.

  The full explicit resource management proposal can be found here.

  Driver now supports auto selecting between IPv4 and IPv6 connections

  For users on Node versions that support the autoSelectFamily and autoSelectFamilyAttemptTimeout options (Node 18.13+), they can now be provided to the MongoClient and will be passed through to socket creation. autoSelectFamily will default to true with autoSelectFamilyAttemptTimeout by default not defined. Example:

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

  Allow passing through allowPartialTrustChain Node.js TLS option

  This option is now exposed through the MongoClient constructor's options parameter and controls the X509_V_FLAG_PARTIAL_CHAIN OpenSSL flag.

  Fixed enableUtf8Validation option

  Starting in v6.8.0 we inadvertently removed the ability to disable UTF-8 validation when deserializing BSON. Validation is normally a good thing, but it was always meant to be configurable and the recent Node.js runtime issues (v22.7.0) make this option indispensable for avoiding errors from mistakenly generated invalid UTF-8 bytes.

  Add duration indicating time elapsed between connection creation and when the connection is ready

  ConnectionReadyEvent now has a durationMS property that represents the time between the connection creation event and when the connection ready event is fired.

  Add duration indicating time elapsed between the beginning and end of a connection checkout operation

  ConnectionCheckedOutEvent/ConnectionCheckFailedEvent now have a durationMS property that represents the time between checkout start and success/failure.

  Create native cryptoCallbacks 🔐

  Node.js bundles OpenSSL, which means we can access the crypto APIs from C++ directly, avoiding the need to define them in JavaScript and call back into the JS engine to perform encryption. Now, when running the bindings in a version of Node.js that bundles OpenSSL 3 (should correspond to Node.js 18+), the cryptoCallbacks option will be ignored and C++ defined callbacks will be used instead. This improves the performance of encryption dramatically, as much as 5x faster. 🚀

  This improvement was made to mongodb-client-encryption@6.1.0 which is available now!

  Only permit mongocryptd spawn path and arguments to be own properties

  We have added some defensive programming to the options that specify spawn path and spawn arguments for mongocryptd due to the sensitivity of the system resource they control, namely, launching a process. Now, mongocryptdSpawnPath and mongocryptdSpawnArgs must be own properties of autoEncryption.extraOptions. This makes it more difficult for a global prototype pollution bug related to these options to occur.

  Support for range v2: Queryable Encryption supports range queries

  Queryable encryption range queries are now officially supported. To use this feature, you must:

  • use a version of mongodb-client-encryption > 6.1.0
  • use a Node driver version > 6.9.0
  • use an 8.0+ MongoDB enterprise server

  Important

  Collections and documents encrypted with range queryable fields with a 7.0 server are not compatible with range queries on 8.0 servers.

  Documentation for queryable encryption can be found in the MongoDB server manual.

  insertMany and bulkWrite accept ReadonlyArray inputs

  This improves the typescript developer experience, developers tend to use ReadonlyArray because it can help understand where mutations are made and when enabling noUncheckedIndexedAccess leads to a better type narrowing experience.

  Please note, that the array is read only but not the documents, the driver adds _id fields to your documents unless you request that the server generate the _id with forceServerObjectId

  Fix retryability criteria for write concern errors on pre-4.4 sharded clusters

  Previously, the driver would erroneously retry writes on pre-4.4 sharded clusters based on a nested code in the server response (error.result.writeConcernError.code). Per the common drivers specification, retryability should be based on the top-level code (error.code). With this fix, the driver avoids unnecessary retries.

  The LocalKMSProviderConfiguration's key property accepts Binary for auto encryption

  In #4160 we fixed a type issue where a local KMS provider at runtime accepted a BSON Binary instance but the Typescript inaccurately only permitted Buffer and string. The same change has now been applied to AutoEncryptionOptions.

  BulkOperationBase (superclass of UnorderedBulkOperation and OrderedBulkOperation) now reports length property in Typescript

  The length getter for these classes was defined manually using Object.defineProperty which hid it from typescript. Thanks to @ sis0k0 we now have the getter defined on the class, which is functionally the same, but a greatly improved DX when working with types. 🎉

  MongoWriteConcernError.code is overwritten by nested code within MongoWriteConcernError.result.writeConcernError.code

  MongoWriteConcernError is now correctly formed such that the original top-level code is preserved

  • If no top-level code exists, MongoWriteConcernError.code should be set to MongoWriteConcernError.result.writeConcernError.code
  • If a top-level code is passed into the constructor, it shouldn't be changed or overwritten by the nested writeConcernError.code

  Optimized cursor.toArray()

  Prior to this change, toArray() simply used the cursor's async iterator API, which parses BSON documents lazily (see more here). toArray(), however, eagerly fetches the entire set of results, pushing each document into the returned array. As such, toArray does not have the same benefits from lazy parsing as other parts of the cursor API.

  With this change, when toArray() accumulates documents, it empties the current batch of documents into the array before calling the async iterator again, which means each iteration will fetch the next batch rather than wrap each document in a promise. This allows the cursor.toArray() to avoid the required delays associated with async/await execution, and allows for a performance improvement of up to 5% on average! 🎉

  Note: This performance optimization does not apply if a transform has been provided to cursor.map() before toArray is called.

  Fixed mixed use of cursor.next() and cursor[Symbol.asyncIterator]

  In 6.8.0, we inadvertently prevented the use of cursor.next() along with using for await syntax to iterate cursors. If your code made use of the following pattern and the call to cursor.next retrieved all your documents in the first batch, then the for-await loop would never be entered. This issue is now fixed.

  const firstDoc = await cursor.next();

  for await (const doc of cursor) {
  // process doc
  // ...
  }

  Features

  • NODE-5459: add durations to connection pool events (#4166) (7295695)
  • NODE-5614: add support for explicit resource management (#4177) (b3f3987)
  • NODE-5754: allow auto select family options (#4185) (54efb7d)
  • NODE-5908: support range v2 (#4141) (de253a7)
  • NODE-6225: add property ownership check before referencing mongocryptdSpawnPath and mongocryptdSpawnArgs (#4151) (

[sourcery-ai]

Reviewer's Guide by Sourcery

This PR upgrades the mongodb package from version 6.9.0 to 6.10.0. The new version introduces several significant features including a new client bulk write API for MongoDB 8.0+ servers, improved SRV hostname support, and maxTimeMS support for explain commands.

Class diagram for ClientBulkWriteModel

classDiagram
    class ClientBulkWriteModel {
        +String namespace
        +String name
        +Document document
        +Document filter
        +Document update
        +Document[] arrayFilters
        +Document hint
        +Document collation
        +boolean upsert
    }
    note for ClientBulkWriteModel "Represents a model for bulk write operations in MongoDB 8.0+ servers."

Loading

Class diagram for ClientBulkWriteResult

classDiagram
    class ClientBulkWriteResult {
        +boolean acknowledged
        +int insertedCount
        +int upsertedCount
        +int matchedCount
        +int modifiedCount
        +int deletedCount
        +ReadonlyMap<int, ClientInsertOneResult> insertResults
        +ReadonlyMap<int, ClientUpdateResult> updateResults
        +ReadonlyMap<int, ClientDeleteResult> deleteResults
    }
    note for ClientBulkWriteResult "Represents the result of a bulk write operation."

Loading

File-Level Changes

Change	Details	Files
Introduces new client bulk write API for MongoDB 8.0+ servers	Adds support for bulk writes across multiple databases and collections in a single call Implements new models for insertOne, updateOne, updateMany, replaceOne, deleteOne, and deleteMany operations Adds support for ordered and unordered bulk writes with verbose results Includes error handling with MongoClientBulkWriteError	package.json package-lock.json
Enhances SRV hostname support	Allows SRV hostnames with fewer than three dot-separated parts Adds validation to ensure returned addresses end with the entire SRV hostname Requires at least one additional domain level for security	package.json package-lock.json
Adds maxTimeMS support for explain commands	Allows specifying maxTimeMS for explain operations Supports maxTimeMS in both fluent cursor API and options object Applies maxTimeMS correctly to both explain command and explained operation	package.json package-lock.json
Removes support for MongoDB 3.6 and MONGODB-CR authentication	Removes compatibility with MongoDB server versions 3.6 and lower Removes support for MONGODB-CR authentication mechanism	package.json package-lock.json

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time. You can also use
  this command to specify where the summary should be inserted.

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[coderabbitai]

Important

Review skipped

Ignore keyword(s) in the title.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

---

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[sourcery-ai]

We have skipped reviewing this pull request. It seems to have been created by a bot ('[Snyk]' found in title). We assume it knows what it's doing!

[socket-security]

New and removed dependencies detected. Learn more about Socket for GitHub ↗︎

Package	New capabilities	Transitives	Size	Publisher
npm/mongodb@6.10.0	environment, filesystem, network, shell	+11	7.02 MB	dbx-node

🚮 Removed packages: npm/mongodb@6.9.0

View full report↗︎

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud