What causes " " in mongodb/node-mongodb-native?

Inspect err.code and err.codeName on the caught MongoServerError to determine the server-side cause; the message is server-generated and dynamic.

mongodb/node-mongodb-native · error · MongoServerError

<dynamic: server error response propagated via MongoServerEr

Error message

<dynamic: server error response propagated via MongoServerError(res)>

What it means

After a deleteOne command completes, the driver inspects the server response in DeleteOneOperation.handleOk (src/operations/delete.ts:116). If the response carries a top-level error code, the entire response document is wrapped in a MongoServerError and thrown. This surfaces command-level failures such as write-concern timeouts, authorization failures, or namespace errors that the server reports at the command level rather than per-document.

Source

Thrown at src/operations/delete.ts:116

    return command;
  }
}

export class DeleteOneOperation extends DeleteOperation {
  constructor(ns: MongoDBCollectionNamespace, filter: Document, options: DeleteOptions) {
    super(ns, [makeDeleteStatement(filter, { ...options, limit: 1 })], options);
  }

  override handleOk(
    response: InstanceType<typeof this.SERVER_COMMAND_RESPONSE_TYPE>
  ): DeleteResult {
    const res = super.handleOk(response);

    // @ts-expect-error Explain commands have broken TS
    if (this.explain) return res;

    if (res.code) throw new MongoServerError(res);
    if (res.writeErrors) throw new MongoServerError(res.writeErrors[0]);

    return {
      acknowledged: this.writeConcern?.w !== 0,
      deletedCount: res.n
    };
  }
}
export class DeleteManyOperation extends DeleteOperation {
  constructor(ns: MongoDBCollectionNamespace, filter: Document, options: DeleteOptions) {
    super(ns, [makeDeleteStatement(filter, options)], options);
  }

  override handleOk(
    response: InstanceType<typeof this.SERVER_COMMAND_RESPONSE_TYPE>
  ): DeleteResult {
    const res = super.handleOk(response);

View on GitHub (pinned to 3366c21a63)

Solutions

Inspect err.code and err.codeName on the caught MongoServerError to determine the server-side cause; the message is server-generated and dynamic.
If err.code is 64 (WriteConcernFailed / wtimeout), verify replica set health and the secondary lag, then retry or lower the write concern.
If err.code is 13 (Unauthorized), check the authenticated user's roles and permissions on the target namespace.
Add retry logic only for transient codes using the RetryableError label (err.hasErrorLabel('RetryableError')).

Example fix

// before
const result = await collection.deleteOne({ _id });
console.log(result.deletedCount);

// after
try {
  const result = await collection.deleteOne({ _id });
  console.log(result.deletedCount);
} catch (err) {
  if (err instanceof MongoServerError) {
    console.error(`server error ${err.code}: ${err.message}`);
    if (err.code === 64) {
      // write concern timeout — check replica set health
    }
  }
  throw err;
}

Defensive patterns

Strategy: try-catch

Validate before calling

// Validate write concern and permissions before deleteOne is impractical client-side;
// instead ensure the client has adequate privileges and a healthy write concern:
if (collection.writeConcern?.w === 0) {
  // unacknowledged — server errors will not propagate; switch to acknowledged
}

Try / catch

try {
  await collection.deleteOne(filter);
} catch (err) {
  if (err instanceof MongoServerError) {
    // err.code and err.message are server-supplied
    switch (err.code) {
      case 64: /* WriteConcernFailed */ break;
      case 13: /* Unauthorized */ break;
      default: throw err;
    }
  } else throw err;
}

Prevention

Use an acknowledged write concern (w >= 1) so server errors are reported.
Ensure the authenticated user has remove privileges on the namespace.
Monitor replica set health to avoid write-concern timeouts.

When it happens

Trigger: Calling collection.deleteOne(filter) and the server returns a response object whose `code` field is set — e.g. writeConcern timeout (code 64), Unauthorized (code 13), or a failed retryable-write commitment after a failover.

Common situations: Write concern `wtimeout` exceeded on a replica set, insufficient permissions for the authenticated user, sharded cluster shard-key errors, or a failover where the original primary could not replicate the write before reporting back.

Related errors

AI-assisted analysis of mongodb/node-mongodb-native@3366c21a63 (2026-08-04). Data as JSON: /data/errors/dd4b43c51035430a.json. Report an issue: GitHub.