MongoServerError: Cursor session id is not the same as the operation context's session id (none)

[phunguyen19]

During query to database, sometimes I get the error:

MongoServerError: Cursor session id (fe781cba-7062-4c28-ad79-88544d696c64 - I9GqUtKwYh3jtwnATekhpsV0cA7X2u2fd3oYCF2c07k=) is not the same as the operation context's session id (none)
    at MessageStream.messageHandler (/var/task/node_modules/mongodb/lib/cmap/connection.js:467:30)
    at MessageStream.emit (events.js:314:20)
    at MessageStream.EventEmitter.emit (domain.js:483:12)
    at processIncomingData (/var/task/node_modules/mongodb/lib/cmap/message_stream.js:108:16)
    at MessageStream._write (/var/task/node_modules/mongodb/lib/cmap/message_stream.js:28:9)
    at doWrite (_stream_writable.js:403:12)
    at writeOrBuffer (_stream_writable.js:387:5)
    at MessageStream.Writable.write (_stream_writable.js:318:11)
    at TLSSocket.ondata (_stream_readable.js:718:22)
    at TLSSocket.emit (events.js:314:20) {
  operationTime: new Timestamp({ t: 1644886783, i: 3 }),
  ok: 0,
  code: 13,
  codeName: 'Unauthorized',
  '$clusterTime': {
    clusterTime: new Timestamp({ t: 1644886783, i: 27 }),
    signature: {
      hash: new Binary(Buffer.from("18ae9ba96ba7ccda512aa002a1154114d2051c77", "hex"), 0),
      keyId: new Long("7048183891290488836")
    }
  }
}

My code was just simple:

PlantModel
    .find({ type })
    .select('plantId  type -_id')
    .sort({ type: 1 })
    .lean();

I have done working around with { skipSession: true }:

PlantModel
    .find(
      { type },
      { plantId: 1, type: 1, _id: 0 },
      { skipSession: true }, 
    )
    .sort({ type: 1 })
    .lean();

Information:

• NodeJS version: AWS Lambda
• AWS Lambda runtime: Node.js 12.x
• AWS Lambda architecture: x86_64
• Mongoose version: 6.1.8

[Uzlopak]

Does Aws Always Put the operations into sessions?

[fzn0x]

You can try https://stackoverflow.com/a/69228547 or create retry mechanism on db.open

[mikewyszinski]

this is happening in my project as wellrunning in AWS lambda, it works about 90% of the time but then fails with theses errors, loooking for any kind on mongoose compatible workaround

[vkarpov15]

Just to confirm, are you using await?

await PlantModel
    .find(
      { type },
      { plantId: 1, type: 1, _id: 0 },
      { skipSession: true }, 
    )
    .sort({ type: 1 })
    .lean();

If not, you might have a query that's still running when your Lambda goes to sleep, which might explain this issue. Either way, without a more complete code sample, not much we can do.

[KubeCowboy]

We just began experiencing this issue on 6.2.11 @vkarpov15

/usr/src/app/node_modules/mongoose/node_modules/mongodb/lib/cmap/connection.js:462
                    callback(new error_1.MongoServerError(document));
                             ^

MongoServerError: Cursor session id (none) is not the same as the operation context's session id (a873374a-27ca-4a02-b5bc-834f9069b743 - jJRDszIUbrneZpUk2EQI+fpcj/SrV8tL7NkbuU2UkIA=)
    at MessageStream.messageHandler (/usr/src/app/node_modules/mongoose/node_modules/mongodb/lib/cmap/connection.js:462:30)
    at MessageStream.emit (node:events:527:28)
    at processIncomingData (/usr/src/app/node_modules/mongoose/node_modules/mongodb/lib/cmap/message_stream.js:108:16)
    at MessageStream._write (/usr/src/app/node_modules/mongoose/node_modules/mongodb/lib/cmap/message_stream.js:28:9)
    at writeOrBuffer (node:internal/streams/writable:389:12)
    at _write (node:internal/streams/writable:330:10)
    at MessageStream.Writable.write (node:internal/streams/writable:334:10)
    at TLSSocket.ondata (node:internal/streams/readable:754:22)
    at TLSSocket.emit (node:events:527:28)
    at addChunk (node:internal/streams/readable:315:12)
    at readableAddChunk (node:internal/streams/readable:289:9)
    at TLSSocket.Readable.push (node:internal/streams/readable:228:10)
    at TLSWrap.onStreamRead (node:internal/stream_base_commons:190:23) {
  operationTime: Timestamp { low: 5, high: 1653629102, unsigned: true },
  ok: 0,
  code: 13,
  codeName: 'Unauthorized',
  '$clusterTime': {
    clusterTime: Timestamp { low: 5, high: 1653629102, unsigned: true },
    signature: {
      hash: Binary {
        sub_type: 0,
        buffer: Buffer(20) [Uint8Array] [
           35,  60,  63, 229, 43,  99,
          125, 241,  52,  38, 68, 187,
          133,  37, 204, 152, 34, 156,
           72,  49
        ],
        position: 20
      },
      keyId: Long { low: 14, high: 1640452857, unsigned: false }
    }
  }
}

It began suddenly in production.

UPDATE:
For us, this was because the connection strings used by the application instances used w=0. Removing this and requiring write acks fixed the issue.