mongodb

Postconditions — what we check

• connect · connection-failure

  error
  WhenNetwork error, authentication failure, or server selection timeout
  ThrowsMongoNetworkError, MongoServerSelectionError, MongoNetworkTimeoutError, or MongoError
  Required handlingCaller MUST catch connection errors and handle them separately from query errors. Implement retry logic with exponential backoff for transient connection issues. Log connection errors for operations monitoring.
  costcriticalin prodimmediate exceptionusers seeservice unavailablevisibilitycatastrophic
  Sources[1]
• find · query-failure

  error
  WhenNetwork error, timeout, or invalid query syntax
  ThrowsMongoServerError, MongoNetworkError, or MongoError
  Required handlingCaller MUST catch query errors. Network errors (MongoNetworkError) may be transient and can be retried. Invalid query errors (MongoServerError) should not be retried.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2]
• findOne · query-failure

  error
  WhenNetwork error, timeout, or invalid query
  ThrowsMongoServerError, MongoNetworkError, or MongoError
  Required handlingCaller MUST catch query errors. Returns null if no document matches (not an error). Network errors may be transient and retriable.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2]
• insertOne · duplicate-key

  error
  WhenDocument violates unique index constraint
  ThrowsMongoServerError with error.code === 11000
  Required handlingCaller MUST catch duplicate key errors (code 11000) and handle gracefully. Extract conflicting field from error message. DO NOT retry without changing the unique field value.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• insertMany · bulk-write-failure

  error
  WhenOne or more documents failed to insert
  ThrowsMongoBulkWriteError with details of failed operations
  Required handlingCaller MUST catch bulk write errors. Check error.result to see which documents succeeded and which failed. Handle partial success scenarios appropriately.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• updateOne · update-failure

  error
  WhenNetwork error, invalid update operation, or write concern failure
  ThrowsMongoServerError, MongoWriteConcernError, or MongoError
  Required handlingCaller MUST catch update errors. Network errors may be transient. Invalid update operators (MongoServerError) should not be retried.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• updateMany · bulk-update-failure

  error
  WhenUpdate operation failed or write concern not satisfied
  ThrowsMongoServerError, MongoWriteConcernError, or MongoError
  Required handlingCaller MUST catch bulk update errors. Check result.modifiedCount to verify how many documents were updated. Implement retry logic for transient failures.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• deleteOne · delete-failure

  error
  WhenNetwork error or write concern failure
  ThrowsMongoServerError, MongoWriteConcernError, or MongoError
  Required handlingCaller MUST catch delete errors. Deleting non-existent document is NOT an error (deletedCount = 0). Network errors may be transient and retriable.
  costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• deleteMany · bulk-delete-failure

  error
  WhenDelete operation failed or write concern not satisfied
  ThrowsMongoServerError, MongoWriteConcernError, or MongoError
  Required handlingCaller MUST catch bulk delete errors. Check result.deletedCount to verify how many documents were deleted. Implement retry logic for transient failures.
  costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• aggregate · aggregation-failure

  error
  WhenInvalid pipeline stage, network error, or timeout
  ThrowsMongoServerError, MongoNetworkError, or MongoError
  Required handlingCaller MUST catch aggregation errors. Pipeline syntax errors (MongoServerError) should not be retried. Network errors may be transient and retriable.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2]
• countDocuments · count-failure

  error
  WhenNetwork error, timeout, or invalid filter
  ThrowsMongoServerError, MongoNetworkError, or MongoError
  Required handlingCaller MUST catch count errors. Network errors may be transient. Invalid filters should not be retried.
  costlowin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2]
• createIndex · index-creation-failure

  error
  WhenInvalid index options, duplicate index name, or insufficient permissions
  ThrowsMongoServerError or MongoError
  Required handlingCaller MUST catch index creation errors. Index with same name but different options will fail. Check if index already exists before creating.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2]
• drop · drop-failure

  error
  WhenCollection does not exist, insufficient permissions, or network error
  ThrowsMongoServerError or MongoError
  Required handlingCaller MUST catch drop errors. Dropping non-existent collection throws error. Use dropCollection with ifExists option to avoid errors.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• collection · collection-access-failure

  error
  WhenInvalid collection name or database not connected
  ThrowsMongoError
  Required handlingCaller MUST catch collection access errors. Ensure database connection is established before accessing collections. Validate collection names before use.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2]
• bulkWrite · bulk-write-failure

  error
  WhenOne or more operations failed
  ThrowsMongoBulkWriteError with details of failed operations
  Required handlingCaller MUST catch bulk write errors. Check error.result for success/failure details of each operation. Handle partial success appropriately.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[2]
• findOneAndUpdate · findoneandupdate-null-not-found

  error
  WhenNo document matches the filter (default behavior without upsert)
  ThrowsReturns null — does NOT throw
  Required handlingCaller MUST check for null return. Treating null as success is the most common production bug with findOneAndUpdate. When the document is expected to exist (e.g., optimistic lock update), null return means another process deleted it. Use returnDocument: 'after' and check result before proceeding. If existence is mandatory, use findOneAndUpdateOrThrow pattern or assert null explicitly.
  costhighin prodsilent failureusers seelost datavisibilitysilent
  Sources[3][4]
• findOneAndUpdate · findoneandupdate-write-concern-error

  error
  WhenWrite concern requirements not met (replica set not acknowledging)
  ThrowsMongoWriteConcernError
  Required handlingCaller MUST catch MongoWriteConcernError. The write may or may not have been applied — write concern error means acknowledgment failed, not necessarily that the write failed. Implement retry with idempotency checks.
  costhighin proddelayed failureusers seelost datavisibilitysilent
  Sources[2][5]
• findOneAndUpdate · findoneandupdate-duplicate-key-upsert

  error
  Whenupsert:true and unique index conflict when inserting new document
  ThrowsMongoServerError with error.code === 11000
  Required handlingCaller MUST catch MongoServerError with code 11000 when using upsert:true. This happens in high-concurrency scenarios when two requests both try to upsert the same document simultaneously. The second upsert fails with duplicate key error.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[6]
• findOneAndDelete · findoneanddelete-null-not-found

  error
  WhenNo document matches the filter
  ThrowsReturns null — does NOT throw
  Required handlingCaller MUST check for null return. A null return means no document was deleted. In queue/dequeue patterns (popping tasks from a queue), null means the queue is empty — must be handled explicitly. Do not attempt to access properties of the null result.
  costmediumin prodsilent failureusers seelost datavisibilitysilent
  Sources[2][4]
• findOneAndDelete · findoneanddelete-network-error

  error
  WhenNetwork error or server unavailable during delete
  ThrowsMongoNetworkError or MongoServerSelectionError
  Required handlingCaller MUST catch network errors. After a network error during findOneAndDelete, the delete state is unknown — the document may or may not have been deleted. Do not retry without checking current state first.
  costhighin proddelayed failureusers seesecurity breachvisibilitysilent
  Sources[2]
• findOneAndReplace · findoneandreplace-null-not-found

  error
  WhenNo document matches the filter (and upsert is not set)
  ThrowsReturns null — does NOT throw
  Required handlingCaller MUST check for null return. Null means no document was found and replaced. Unlike updateOne which returns matchedCount:0, findOneAndReplace returns null. Check result before proceeding with any logic that depends on the replaced document.
  costmediumin prodsilent failureusers seelost datavisibilitysilent
  Sources[2]
• findOneAndReplace · findoneandreplace-validation-error

  error
  WhenReplacement document violates schema validation rules
  ThrowsMongoServerError with codeName: 'DocumentValidationFailure'
  Required handlingCaller MUST catch MongoServerError. Unlike findOneAndUpdate (which applies an update operator), findOneAndReplace replaces the entire document — schema validation applies to the full replacement document. Check schema validation rules before replacing.
  costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[7]
• withTransaction · withtransaction-transient-error-not-retried-externally

  error
  WhenNon-transient error thrown by callback operation
  ThrowsMongoServerError, MongoNetworkError, or MongoError — propagated from callback
  Required handlingCaller MUST wrap withTransaction in try-catch. withTransaction automatically retries TransientTransactionError and UnknownTransactionCommitResult. Any other error propagates to caller. Do NOT wrap callback operations in their own try-catch unless you re-throw — swallowing errors inside the callback prevents withTransaction's retry logic from firing.
  costcriticalin prodsilent failureusers seelost datavisibilitysilent
  Sources[8][9]
• withTransaction · withtransaction-write-conflict

  error
  WhenTwo concurrent transactions modify the same document (WriteConflict)
  ThrowsMongoServerError with code 112 (WriteConflict) — labeled TransientTransactionError
  Required handlingwithTransaction automatically retries WriteConflict errors when labeled TransientTransactionError. However if the total elapsed time exceeds 120 seconds, the error propagates. Caller MUST handle the propagated error. Keep transactions short to minimize conflict window.
  costhighin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[8][9]
• withTransaction · withtransaction-session-required

  error
  WhenAll operations inside callback must use the session parameter
  ThrowsOperations without session bypass transaction — no error thrown, silent data corruption
  Required handlingCRITICAL: Every MongoDB operation inside the withTransaction callback MUST pass the session object (e.g., collection.insertOne(doc, { session })). Operations without the session parameter run outside the transaction — they commit immediately regardless of whether the overall transaction commits or aborts. This is a logic error, not an exception.
  costcriticalin prodsilent failureusers seelost datavisibilitysilent
  Sources[9][8]
• watch · watch-error-event-not-thrown

  error
  WhenNetwork disconnection, resume token expiration, or oplog rollover
  ThrowsEmits 'error' event on the ChangeStream — does NOT throw
  Required handlingCaller MUST attach an 'error' event listener to the ChangeStream before using it. Without an error listener, unhandled 'error' events crash the Node.js process. The ChangeStream attempts automatic resume after transient errors (MongoNetworkError) but emits 'error' for unresumable failures (e.g., oplog rolled over past resume token). Pattern: changeStream.on('error', (err) => { /* log and reconnect */ });
  costcriticalin prodimmediate exceptionusers seeservice unavailablevisibilitycatastrophic
  Sources[10][2]
• watch · watch-resume-token-expired

  error
  WhenResume token references a position that has been rolled off the oplog
  ThrowsEmits 'error' event with MongoServerError — ChangeStream cannot resume
  Required handlingCaller MUST handle the 'error' event and implement a full restart strategy (not just resume) when the resume token has expired. The ChangeStream cannot recover from oplog rollover — the stream must be re-opened from the current oplog position, and the application must re-sync any missed changes via a full collection scan or checkpoint.
  costhighin proddelayed failureusers seelost datavisibilitysilent
  Sources[11]
• replaceOne · replaceone-validation-failure

  error
  WhenReplacement document fails server-side schema validation
  ThrowsMongoServerError with codeName: 'DocumentValidationFailure'
  Required handlingCaller MUST catch MongoServerError. replaceOne replaces the entire document, so all required fields must be present in the replacement. Schema validation errors are not thrown by updateOne for partial updates but ARE thrown by replaceOne for missing required fields in the replacement.
  costmediumin prodimmediate exceptionusers seelost datavisibilityvisible
  Sources[7][2]
• replaceOne · replaceone-network-error

  error
  WhenNetwork error during replacement
  ThrowsMongoNetworkError or MongoServerSelectionError
  Required handlingCaller MUST catch network errors. replaceOne is NOT idempotent if the replacement document contains different data — retrying without checking whether the replacement was applied may replace data that was already replaced correctly.
  costmediumin proddelayed failureusers seelost datavisibilitysilent
  Sources[2]
• close · close-not-called-resource-leak

  warning
  WhenMongoClient.close() never called before process exit
  ThrowsDoes not throw — process exits with open connections
  Required handlingCaller MUST call client.close() in a finally block or process shutdown handler. Open connections at exit cause connection pool exhaustion on the MongoDB server (connections are not returned to the pool on abrupt exit). Pattern: process.on('SIGTERM', async () => { await client.close(); process.exit(0); }); Or: try { await operations(); } finally { await client.close(); }
  costmediumin proddelayed failureusers seeservice unavailablevisibilityvisible
  Sources[2][12]
• close · close-operations-in-flight

  error
  Whenclose() called while operations are still in progress
  ThrowsIn-progress operations throw MongoClientClosedError
  Required handlingCaller MUST ensure all in-progress operations complete (or are cancelled) before calling close(). Use await to drain operation promises before calling close(). In graceful shutdown: stop accepting new requests, wait for current requests to complete, then close.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[13]
• dropIndex · dropindex-not-found

  error
  WhenSpecified index does not exist
  ThrowsMongoServerError with codeName: 'IndexNotFound' or code 27
  Required handlingCaller MUST catch MongoServerError and check for IndexNotFound. Unlike dropIndexes() (which succeeds even with no indexes), dropIndex() throws when the named index does not exist. Use createIndex first to ensure existence, or catch and ignore IndexNotFound specifically.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[2][14]
• createCollection · createcollection-namespace-exists

  error
  WhenA collection with the same name already exists in the database. This is the most common error for createCollection() in migration/startup code. If the collection was created by a previous migration run, a second call throws instead of being idempotent.
  ThrowsMongoServerError with code 48 (NamespaceExists) and codeName: 'NamespaceExists'. The error message is: "Collection <dbname>.<name> already exists."
  Required handlingCaller MUST catch MongoServerError code 48 and handle idempotently. Two patterns: Option 1 (recommended): Use Db.listCollections() to check first, or catch and ignore: try { await db.createCollection('users', { validator: { $jsonSchema: { ... } } }); } catch (error) { if (error instanceof MongoServerError && error.code === 48) { // Collection already exists — safe to ignore in idempotent migrations } else { throw error; } } Option 2: Pass { checkExistingFieldNames: false } if using schema validation and collection may already exist. CRITICAL: Do NOT ignore all MongoServerError — code 48 is idempotent-safe, but other codes (schema validation syntax errors, permission denied) must propagate.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[15][16][17]
• createCollection · createcollection-validation-schema-error

  error
  WhenThe validator option specifies an invalid JSON schema — syntax errors, unknown keywords, or invalid $jsonSchema values. Also thrown when schema contains Queryable Encryption (FLE2) fields but the MongoDB server version is below the minimum required for encrypted collections (< 7.0 wire protocol version 21).
  ThrowsMongoServerError with codeName: 'BadValue' for invalid schema syntax. MongoCompatibilityError (extends MongoDriverError) with message: "Driver support of Queryable Encryption is incompatible with server..." when FLE2 encrypted fields are used against an older server. Confirmed from create_collection.js: 'throw new MongoCompatibilityError(INVALID_QE_VERSION)'.
  Required handlingCaller MUST catch both MongoServerError (schema syntax) and MongoCompatibilityError (FLE2 version mismatch) in startup/migration paths. A schema validation error in startup silently skips collection configuration in some frameworks (Next.js swallows module-load errors) — always log and halt. try { await db.createCollection('products', { validator: { $jsonSchema: { bsonType: 'object', required: ['name'] } } }); } catch (error) { if (error instanceof MongoCompatibilityError) { console.error('Server too old for encrypted collections:', error.message); process.exit(1); } if (error instanceof MongoServerError && error.code === 48) { // Already exists — acceptable in idempotent migrations } else if (error instanceof MongoServerError) { console.error('Invalid collection config:', error.message); throw error; } }
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[17][16]
• distinct · distinct-no-try-catch

  error
  Whendistinct() is called without try-catch. If the collection or database is unavailable (network failure, server selection timeout), or if the key field path is invalid according to server-side rules, the Promise rejects. Common in API endpoints that return facet values for UI dropdowns — an uncaught error returns a 500 instead of an empty facet list.
  ThrowsMongoServerError (invalid field path or server-side validation failure), MongoNetworkError (network failure — connection dropped), MongoServerSelectionError (no server available within serverSelectionTimeoutMS), MongoError (catch-all base class for all MongoDB errors). Returns empty array [] when no documents match — does NOT throw.
  Required handlingCaller MUST wrap distinct() in try-catch. Returning [] on error is often acceptable for non-critical facet endpoints: try { const categories = await collection.distinct('category', { status: 'active' }); return categories; } catch (error) { if (error instanceof MongoNetworkError) { // Transient — retry or return stale cached values throw error; } if (error instanceof MongoServerError) { // Field path invalid or server error — log and return empty console.error('distinct failed:', error.message, error.code); return []; } throw error; } Note: distinct() returns [] when the query matches no documents. An empty result is NOT an error and must not be confused with a failed query.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[18][19]
• createIndexes · createindexes-options-conflict

  error
  WhenAn index with the same key spec already exists but with different options (e.g., same fields but different unique/sparse/collation settings). MongoDB rejects index creation when the name or key spec conflicts with an existing index definition. Common in deployments where index options are changed between app versions.
  ThrowsMongoServerError with code 85 (IndexOptionsConflict) when an existing index has the same name but different options, or code 86 (IndexKeySpecsConflict) when the same key spec exists under a different index name. Neither is idempotent-safe. Confirmed from MongoDB server error codes reference.
  Required handlingCaller MUST catch MongoServerError and check the code. createIndexes() is idempotent for identical index definitions (same key + same options), but throws on conflicting definitions. In migration code: try { await collection.createIndexes([ { key: { email: 1 }, name: 'email_unique', unique: true }, { key: { createdAt: -1 }, name: 'created_at_desc', expireAfterSeconds: 86400 } ]); } catch (error) { if (error instanceof MongoServerError && (error.code === 85 || error.code === 86)) { // Index conflict — need to drop and recreate, or update migration script console.error('Index conflict — cannot create:', error.message); throw error; } throw error; } To safely update an existing index, call dropIndex() with the conflicting name before calling createIndexes() in the same migration transaction.
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[15][20][21]
• dropIndexes · dropindexes-namespace-not-found

  error
  WhendropIndexes() is called on a collection that does not exist in the database. This differs from dropIndex() behavior — while both operate on indexes, dropIndexes() on a non-existent collection throws NamespaceNotFound. Common in migration scripts that attempt to clean up indexes before the collection has been created.
  ThrowsMongoServerError with code 26 (NamespaceNotFound, defined in MONGODB_ERROR_CODES in error.js). Message: "ns not found". Note: dropIndexes() on an existing but empty collection (no non-_id indexes) returns immediately without error.
  Required handlingCaller MUST catch MongoServerError code 26 in migration scripts that may run before collection creation: try { await collection.dropIndexes(); } catch (error) { if (error instanceof MongoServerError && error.code === 26) { // Collection does not exist yet — skip index cleanup console.warn(`Collection ${collection.collectionName} not found — skipping dropIndexes`); } else { throw error; } }
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[14][5]
• withSession · withsession-callback-error-propagates

  error
  WhenThe callback passed to withSession() throws or rejects. Unlike withTransaction(), withSession() does NOT catch or retry errors from the callback — any error thrown inside propagates directly to the caller. endSession() is still called (via finally), but the original error propagates up unchanged. This is a critical behavioral difference from withTransaction().
  ThrowsAny error thrown by the callback propagates unchanged. If the callback performs MongoDB operations without try-catch, typical errors include: MongoNetworkError, MongoServerError, MongoServerSelectionError, or MongoError. The session is always closed via finally, so SESSION_CLOSED or resource leak is NOT the risk here — the callback error is the risk.
  Required handlingCaller MUST wrap withSession() in try-catch OR handle errors inside the callback. This is different from withTransaction() where errors in the callback are retried. A common mistake is using withSession() when withTransaction() was intended: // CORRECT: catch at the withSession call site try { await client.withSession(async (session) => { const docs = await collection.find({}, { session }).toArray(); await otherCollection.insertMany(docs, { session }); }); } catch (error) { console.error('Session operation failed:', error.message); throw error; } Note: endSession() errors are swallowed (squashError) — they do not mask the original callback error. Confirmed from mongo_client.js source.
  costmediumin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[13][22]
• withSession · withsession-operations-missing-session

  warning
  WhenMongoDB operations inside the withSession callback do NOT pass the session object. Operations run without the session are not part of the session's causal consistency chain and will use separate connections from the pool, bypassing the session's read concern and read preference settings.
  ThrowsDoes not throw — silent behavioral error (operations run outside session context)
  Required handlingCRITICAL: Every MongoDB operation inside withSession MUST pass { session }: // WRONG — operations bypass session await client.withSession(async (session) => { const result = await collection.findOne({ _id: id }); // ❌ Missing session return result; }); // CORRECT await client.withSession(async (session) => { const result = await collection.findOne({ _id: id }, { session }); // ✅ return result; }); This is the same session-passing requirement as withTransaction(), but withSession() is used more often for simple operations where the mistake is easier to make.
  costmediumin prodsilent failureusers seedegraded performancevisibilitysilent
  Sources[22][13]
• rename · rename-target-exists

  error
  WhenThe target collection name already exists in the database and dropTarget option is not set to true. By default, rename() refuses to overwrite an existing collection. Common in blue-green migrations where the production collection exists and a new version was loaded into a temp collection.
  ThrowsMongoServerError with message containing "target namespace exists" or similar, from the MongoDB server's renameCollection command. The exact codeName varies by server version. dropTarget: true option allows overwriting.
  Required handlingCaller MUST either set dropTarget: true (destructive) or drop the target first: // Option 1: atomic rename-with-drop (atomic on single-node, not on sharded) await collection.rename('users_new', { dropTarget: true }); // Option 2: drop then rename (two-step, brief downtime window) try { await db.dropCollection('users_backup'); } catch (e) { /* ignore not-found */ } await collection.rename('users_backup'); CRITICAL: dropTarget: true is NOT atomic on sharded clusters — there is a brief window where neither old nor new collection is accessible.
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[23][24]
• rename · rename-no-try-catch

  error
  Whenrename() is called without try-catch. Network errors during the rename admin command (which runs against the admin database) cause the Promise to reject. The rename is atomic on standalone and replica sets but not on sharded clusters.
  ThrowsMongoNetworkError (connection failure during rename command), MongoServerError (insufficient permissions — rename requires admin privileges, or source collection does not exist — NamespaceNotFound code 26).
  Required handlingCaller MUST wrap rename() in try-catch. Source collection not existing is a MongoServerError with NamespaceNotFound (code 26): try { const newCollection = await collection.rename('users_v2'); return newCollection; } catch (error) { if (error instanceof MongoServerError && error.code === 26) { throw new Error(`Source collection does not exist`); } throw error; }
  costhighin prodimmediate exceptionusers seeservice unavailablevisibilityvisible
  Sources[23][24]

Sources

Every postcondition cites at least one of these. Numbered to match the footnotes above.

1. [1]mongodb.com/docs/drivershttps://www.mongodb.com/docs/drivers/node/current/connection-troubleshooting/
2. [2]mongodb.com/docs/drivershttps://www.mongodb.com/docs/drivers/node/current/
3. [3]mongodb.com/docs/drivershttps://www.mongodb.com/docs/drivers/node/current/fundamentals/crud/write-operations/
4. [4]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/operations/find_and_modify.ts
5. [5]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/error.ts
6. [6]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/reference/operator/update/setOnInsert/
7. [7]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/core/schema-validation/
8. [8]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/sessions.ts
9. [9]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/core/transactions/
10. [10]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/change_stream.ts
11. [11]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/changeStreams/#resume-after-errors-or-mongos-failover
12. [12]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native
13. [13]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/mongo_client.ts
14. [14]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/reference/command/dropIndexes/
15. [15]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/reference/error-codes/
16. [16]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/operations/create_collection.ts
17. [17]mongodb.com/docs/drivershttps://www.mongodb.com/docs/drivers/node/current/fundamentals/schema-validation/
18. [18]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/reference/command/distinct/
19. [19]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/operations/distinct.ts
20. [20]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/reference/command/createIndexes/
21. [21]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/operations/indexes.ts
22. [22]mongodb.com/docs/drivershttps://www.mongodb.com/docs/drivers/node/current/fundamentals/sessions/
23. [23]mongodb.com/docs/manualhttps://www.mongodb.com/docs/manual/reference/command/renameCollection/
24. [24]github.com/mongodb/node-mongodb-nativehttps://github.com/mongodb/node-mongodb-native/blob/main/src/operations/rename.ts