If a thread does a write that gets rolled back during stepdown, its client can have _lastOp with timestamp higher than the timestamp of system last opTime (if the wallclock on primary is behind the wallclock on the node the threads runs on). So if after stepdown the thread sends a write command to itself, the command will fail the ReplicationCoordinator check when trying to write an oplog entry but the NotMaster error will get caught in this block in the ServiceEntryPoint::runCommandImpl. Since the command is a noop, the client's lastOp will be set to last system opTime. So after the wait for writeConcern fails, the NotMaster error will get propagated up, and the operation will hit the invariant operationTime >= startOperations when trying append operationTime to the response.
- related to
-
SERVER-30842 Don't try to set last optime for client backwards after rollback
- Closed