43
MongoDBERRORCriticalQuery ErrorHIGH confidence

The specified cursor ID is not found on the server

What this means

This error occurs when a client attempts to get more data (using a `getMore` command) for a cursor that is no longer valid on the server. Cursors are automatically closed by the server after a period of inactivity (typically 10 minutes).

Why it happens
  1. 1A long pause in application processing between batches of results from a query
  2. 2An application taking too long to process a batch of documents, causing the server-side cursor to time out
  3. 3A network partition or server restart that causes the server to lose track of the cursor
  4. 4Explicitly killing the cursor and then trying to fetch more results from it
How to reproduce

An application fetches a batch of documents, waits for more than 10 minutes, and then tries to fetch the next batch.

trigger — this will error
trigger — this will error
// In a driver, this happens automatically during iteration.
const cursor = db.collection.find({});
const firstBatch = await cursor.nextBatch();

// ... wait for 11 minutes ...

// This will likely fail because the cursor has timed out on the server.
const secondBatch = await cursor.nextBatch();

expected output

MongoServerError: Cursor not found, cursor id: ...

Fix 1

Process Results Faster or in Parallel

WHEN Document processing is the bottleneck.

Why this works

Optimize the code that processes each document to reduce the time spent between `getMore` calls. If possible, process documents in parallel to keep the cursor alive.

Fix 2

Use `noCursorTimeout` Option

WHEN You have a legitimate, long-running process that must keep a cursor open.

Use `noCursorTimeout` Option
// Use this option with caution.
const cursor = db.collection.find({}).noCursorTimeout();

Why this works

The `noCursorTimeout` option tells the server not to automatically close this specific cursor due to inactivity. This can be useful for specific background jobs, but it is critical to ensure the cursor is always explicitly closed in the application to prevent resource leaks.

Fix 3

Re-execute the Query

WHEN The operation is idempotent and can be safely restarted.

Why this works

If a cursor is not found, the simplest recovery strategy is to re-run the original query. This is effective if the query is fast and the processing can resume from the beginning.

What not to do

Use `noCursorTimeout` for all queries by default

This is dangerous and can lead to resource exhaustion on the server. If clients disconnect without properly closing these cursors, they will remain open indefinitely, consuming memory and resources on the `mongod` instance.

Sources

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All MongoDB errors