We can fix this by by adding wrapping those write ops in try{..}catch() block.*But my recommendation is to use write_ops_exec::performInserts*() (It’s the entry point to user insert commands).
1) It has logic to _convertExceptionToReturnStatus()
2) we are currently taking X lock on Config database (it’s not correct). We should take IX lock for the Database. Otherwise, it will block any operations in other collections present in config database.
- We don’t need to take collection or db locks in the recipient file, performInserts will take necessary lock.
- Also, if the collection is not present, it will create the collection implicitly before insert.
3) We should disable the document validation for this reason mentioned here. In the current code, we do collection validation().
4) I am not recommending StorageInterfaceImpl::insertDocuments(), it has some limitations. In case, in future, if we try to batch write and do it in single WriteUnitOfWork. Here is an example, where we use performInserts() to insert documents to a replicated collection in config db
Other things I noted:
1) After updating the in-memory state doc state , we are not persisting the updated state doc. It seems it’s depending on this step for state doc persistence, that is after killing backup cursor, and that’s wrong. I believe, my ticket will add logic of copying the donor files to recipient after updating the state and before killing the backup cursor. We need to inform secondaries before the primary starts the file cloning and killing backup cursor.
2) minor NIT: It seems you recently wrapped this shouldStopSendingRecipientSyncDataCommand() in mutex and I assume it’s due to calling getProtocol(). We don’t need to take any mutex lock to read getProtocol() which reads _protocol value.