[SERVER-69262] Majority write on recipient primary may fail trying to acquire database lock Created: 30/Aug/22  Updated: 29/Oct/23  Resolved: 01/Sep/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.2.0-rc0

Type: Bug Priority: Major - P3
Reporter: Matt Broadstone Assignee: Matt Broadstone
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 150

 Description   

appendOplogNote will use a GlobalLock to perform its no-op write, which we may fail to acquire. Shard split must retry the command in this case, instead of conditionally retrying until a non-retriable, or network error is encountered.



 Comments   
Comment by Britt Snyman [ 01/Sep/22 ]

Replacing the 6.1.0-rc1 fixVersion with 6.2.0-rc0 since these tickets had commits to master that were merged after we branched for v6.1.

Comment by Githook User [ 31/Aug/22 ]

Author:

{'name': 'Matt Broadstone', 'email': 'mbroadst@mongodb.com', 'username': 'mbroadst'}

Message: SERVER-69262 Unconditionally retry stepup and no-op write commands
Branch: master
https://github.com/mongodb/mongo/commit/54746da1485cfca77a1f1fd214ee83d3d6948d0d

Generated at Thu Feb 08 06:13:01 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.