mongodb/node-mongodb-native · error · MongoRuntimeError

A collection name must be determined before getMore

Error message

A collection name must be determined before getMore

What it means

Thrown by GetMoreOperation.buildCommand when this.ns.collection is null/undefined, so the getMore command cannot name a target collection. The driver expects every cursor to have adopted a fully-qualified namespace (db + collection) from the server's initial response; a missing collection name means that adoption did not happen. This is a MongoRuntimeError reflecting an inconsistent internal state, almost always triggered through aggregation or special cursors rather than normal find().

Source

Thrown at src/operations/get_more.ts:65

    this.ns = ns;
    this.cursorId = cursorId;
    this.server = server;
  }

  override get commandName() {
    return 'getMore' as const;
  }

  override buildCommand(_connection: Connection): Document {
    if (this.cursorId == null || this.cursorId.isZero()) {
      throw new MongoRuntimeError('Unable to iterate cursor with no id');
    }

    const collection = this.ns.collection;
    if (collection == null) {
      // Cursors should have adopted the namespace returned by MongoDB
      // which should always defined a collection name (even a pseudo one, ex. db.aggregate())
      throw new MongoRuntimeError('A collection name must be determined before getMore');
    }

    const getMoreCmd: GetMoreCommand = {
      getMore: this.cursorId,
      collection
    };

    if (typeof this.options.batchSize === 'number') {
      getMoreCmd.batchSize = Math.abs(this.options.batchSize);
    }

    if (typeof this.options.maxAwaitTimeMS === 'number') {
      getMoreCmd.maxTimeMS = this.options.maxAwaitTimeMS;
    }

    // we check for undefined specifically here to allow falsy values
    // eslint-disable-next-line no-restricted-syntax
    if (this.options.comment !== undefined) {

View on GitHub (pinned to 3366c21a63)

Solutions

  1. If you used a database-level aggregation/change stream, ensure you iterate it through the standard async-iteration API and don't bypass the cursor wrapper.
  2. Reproduce with collection-level operations (collection.aggregate) which always carry a namespace; switch if appropriate.
  3. If the call path is standard and this still fires, capture the operation chain and file a driver bug with the MongoDB version and driver version.
  4. Avoid constructing or mutating cursor namespaces directly from application code.
Defensive patterns

Strategy: try-catch

Try / catch

try {
  await cursor.toArray();
} catch (e) {
  if (e instanceof MongoRuntimeError && /collection name/.test(e.message)) {
    // switch to a collection-scoped operation, or report environment details
  }
  throw e;
}

Prevention

When it happens

Trigger: Iterating a cursor from a command that does not bind a collection namespace (certain database-level aggregations, change streams on a client/database scope, or cursors constructed without a namespace). Also seen when internal namespace handling is bypassed or when a custom operation mis-sets the namespace. Normal collection.find()/aggregate() cursors should not hit this.

Common situations: Using db.aggregate() (no collection) and then mishandling the resulting cursor; driver upgrade where namespace adoption changed; manually constructed/internal cursor usage; rarely, a genuine driver bug worth reporting.

Related errors


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