MongoDB - Erro:comando getMore falhou:Cursor não encontrado

EDIT - Desempenho da consulta:

db.snapshots.find({
    roundedDate: { $exists: true },
    stream: { $exists: true },
    sid: { $exists: false }
})

O que está acontecendo aqui:

• 
  Limite de tempo limite, que é de 10 minutos por padrão. Dos documentos:
  

  
  Por padrão, o servidor fechará automaticamente o cursor após 10 minutos de inatividade ou se o cliente tiver esgotado o cursor.
  

• 
  Tamanho do lote, que é de 101 documentos ou 16 MB para o primeiro lote e 16 MB, independentemente do número de documentos, para lotes subsequentes (a partir do MongoDB 3.4 ). Dos documentos:
  

  
  find() e aggregate() operações têm um tamanho de lote inicial de 101 documentos por padrão. As operações getMore subsequentes emitidas no cursor resultante não têm tamanho de lote padrão, portanto, são limitadas apenas pelo tamanho da mensagem de 16 megabytes.
  

À medida que você percorre o cursor e chega ao final do lote retornado, se houver mais resultados, cursor.next() executará uma operação getMore para recuperar o próximo lote.

Soluções possíveis:

1. 
   👍 Reduzindo o tamanho do lote para manter o cursor vivo.
   
2. 
   👍 Remova o tempo limite do cursor.
   
3. 
   👍 Tente novamente quando o cursor expirar.
   
4. 
   👎 Consulte os resultados em lotes manualmente.
   
5. 
   👎 Obtenha todos os documentos antes que o cursor expire.
   

1. 👍 Reduzindo o tamanho do lote para manter o cursor ativo

const cursor = db.collection.find()
    .batchSize(NUMBER_OF_DOCUMENTS_IN_BATCH);

2. 👍 Remova o tempo limite do cursor

const cursor = db.collection.find().noCursorTimeout();

Depois de definir o noCursorTimeout opção, você deve fechar o cursor manualmente com cursor.close() ou esgotando os resultados do cursor.

• 
  É um recurso suportado pelo driver. Se fosse tão ruim, como existem maneiras alternativas de contornar problemas de tempo limite, conforme explicado nas outras soluções, isso não será suportado.
  
• 
  Existem maneiras de usá-lo com segurança, é apenas uma questão de ser mais cauteloso com ele.
  
• 
  Suponho que você não esteja executando esse tipo de consulta regularmente, portanto, as chances de você começar a deixar cursores abertos em todos os lugares são baixas. Se este não for o caso, e você realmente precisar lidar com essas situações o tempo todo, então faz sentido não usar noCursorTimeout .
  

3. 👍 Tente novamente quando o cursor expirar

let processed = 0;
let updated = 0;

while(true) {
    const cursor = db.snapshots.find().sort({ _id: 1 }).skip(processed);

    try {
        while (cursor.hasNext()) {
            const doc = cursor.next();

            ++processed;

            if (doc.stream && doc.roundedDate && !doc.sid) {
                db.snapshots.update({
                    _id: doc._id
                }, { $set: {
                    sid: `${ doc.stream.valueOf() }-${ doc.roundedDate }`
                }});

                ++updated;
            } 
        }

        break; // Done processing all, exit outer loop
    } catch (err) {
        if (err.code !== 43) {
            // Something else than a timeout went wrong. Abort loop.

            throw err;
        }
    }
}

4. 👎 Consulte os resultados em lotes manualmente

5. 👎 Obtenha todos os documentos antes que o cursor expire

const results = new Array(db.snapshots.find());

Observação sobre o modo instantâneo e documentos duplicados

Anexe o método snapshot() a um cursor para alternar o modo “snapshot”. Isso garante que a consulta não retornará um documento várias vezes, mesmo que as operações de gravação intervenientes resultem em uma movimentação do documento devido ao aumento do tamanho do documento.

• 
  Não funciona com coleções fragmentadas.
  
• 
  Não funciona com sort() ou hint() , portanto não funcionará com as soluções 3 e 4.
  
• 
  Não garante o isolamento de inserções ou exclusões.
  

Observação sobre cursores abertos