If a findAndModify request specifies a sort, we use a limit of 1 to reduce the memory requirements and use a top-k sort. With such a request, if a WriteConflictException is encountered while trying to update or delete a matching document, the operation will return no matches. This happens even if there are other documents that match the query. We should retry the entire operation in this scenario to avoid not returning a document when there were results that matched the query.

Original Description

Using MongoDb with WT to create a simple message queue, I used one writer to add some documents with a state of 'Q'. I then use 50 readers (threads) to consume these documents, with each thread using a FindAndModify query to atomically update the state of a document to 'in process' and return it for processing. At the end of processing the document state is updated to 'processed'.

The query (using the c# driver) looks as follows:

var message = await m_QueueMessages.FindOneAndUpdateAsync(Builders<MongoMessage>.Filter.Where(m => m.QueueType == QueueType.Queued),
                                                                Builders<MongoMessage>.Update.Set(m => m.QueueType, QueueType.InProcess),
                                                                new FindOneAndUpdateOptions<MongoMessage> { Sort = Builders<MongoMessage>.Sort.Ascending(m => m.ObjectId), IsUpsert = false, MaxTime = TimeSpan.FromSeconds(5) },
                                                                CancellationToken.None);

This query often returns null, even though there are documents matching the filter. Removal of the sort apparently fixes this. I have confirmed with Craig Wilson (MongoDb c# driver) that this is not a driver issue.