Info

We have a PSA setup running Mongo 4.0.7. We are using the node.js driver: "mongodb": "3.1.1" In one process we create an object in the db via a call to one of our REST services. The call to insert the object is as follows: const result = await client.db(dbname) .collection(COLLECTION_NAME) .insertOne(clone(alert), { writeConcern: { j: true } }); Once our rest service returns to the calling operation it calls another operation on the rest service passing in the id of the newly created object. The first thing the service does is perform a read in mongo by id. This returns the object. The service then starts a transaction, inserts into some other collections and finally performs a findOneAndUpdate (in the transaction): findOneAndUpdate(query, update, options); The query is just {id: value}, the same object that was used to retrieve the object earlier. The update contains the following operations: {"$inc":{"a":40,"b":1},"$set":{"c.d":1620309757604},"$addToSet":{"e":["f","g"]}} For some reason, on some occasions the update fails to update anything and we see a response like: {"lastErrorObject":{"n":0,"updatedExisting":false},"value":null,"ok":1,"operationTime":"6959177415704707439","$clusterTime":{"clusterTime":"6959177415704707439","signature":{"hash":"AAAAAAAAAAAAAAAAAAAAAAAAAAA=","keyId":0}}} When this happens there are a lot of actions happening in Mongo although there is no  contention on this item. The transaction is then committed successfully (all be it with this missing write). Do you know my the item can be read but then in a transaction it cant be found to be updated? Thanks in advance.

Top User Comments

JIRAUSER1257066 commented on Tue, 25 May 2021 17:14:56 +0000: Hi leigh.jones@ripjar.com, I'll close this since you were able to resolve the issue on your own. If you're still interested in this investigation, please take a look at my reproduction attempt and see if it reflects the implementation that caused your issue, and what changes need to be made to successfully reproduce it. Best, Edwin leigh.jones@ripjar.com commented on Fri, 7 May 2021 10:45:21 +0000: I think this can be closed now. leigh.jones@ripjar.com commented on Fri, 7 May 2021 09:56:41 +0000: I suspect this is caused because the transaction has: supports: { causalConsistency: true } which I think will mean its using read majority, and write majority but (sometimes) the initiall insert hasnt propagated to secondary node yet and so when using read majority it isnt visible. Is this correct? leigh.jones@ripjar.com commented on Fri, 7 May 2021 09:43:50 +0000: Performing a get by id within the context of the transaction does not find the record. Is there a different write concern ( other than w:1, j: true) I should be using here? Why is this record not visible within my transaction? I'm not removing it as part of the transaction. leigh.jones@ripjar.com commented on Fri, 7 May 2021 08:13:10 +0000: As a further update If I get the object by id immediately after the failed update (but outside of a transaction) again the record is found leigh.jones@ripjar.com commented on Thu, 6 May 2021 17:28:48 +0000: In fact looking the all my code / json snippets they all seem to be corrupted to some degree. Please let me know if you need them elaborating leigh.jones@ripjar.com commented on Thu, 6 May 2021 17:27:45 +0000: const result = await client.db(dbname) .collection(COLLECTION_NAME) .insertOne(clone(alert), { writeConcern: Unknown macro: \{ j} }); Should have read: const result = await client.db(dbname) .collection(COLLECTION_NAME) .insertOne(clone(alert), { writeConcern: { j: true }});

Steps to Reproduce