When shard A's Primary steps down and a new Primary is elected, there is a window of time during which the ReplicaSetMonitor on shards other than A still believe the original node is shard A's Primary. It is possible for a $merge to be issued during this window which is dispatched to shard B and will then fail with a NotMaster exception if it attempts to write to shard A, since the writes will be targeted towards a node which is now Secondary. It appears that it is also possible for a CursorNotFound exception to result due to a NotMasterNoSlaveOk exception on shard A if the $merge is dispatched to a shard as part of the latter half of a split pipeline.