-
Type: Bug
-
Resolution: Works as Designed
-
Priority: Major - P3
-
None
-
Affects Version/s: 3.6.0-rc2
-
Component/s: Sharding
-
None
-
ALL
-
-
Sharding 2019-07-01
-
(copied to CRM)
-
60
Command errors such as duplicate key errors still cause the clusterTime to be advanced; however, no oplog entry is written for those failed operations. We then use the current clusterTime as the operationTime in the server's error responses for other error cases (as part of the changes from SERVER-31306), leading a client to wait until a time no operation actually happened at.
The behavior of advancing the clusterTime prior to RecoveryUnit::Change::commit() (e.g. for cases where the operation fails on WiredTiger transaction commit) may have other negative effects on causal consistency that I haven't thought about. The impact of this bug insofar as I have observed failures in Evergreen is that we no longer have a guarantee of making forward progress when waiting for afterClusterTime unless the periodic no-op writer is running.
- is related to
-
SERVER-31306 $clusterTime not included in response with ReadConcernMajorityNotEnabled error
- Closed
-
SERVER-35156 secondary reads return cluster time as the operation time
- Closed
-
SERVER-35377 Operations on new clients get latest in-memory clusterTime as operationTime
- Closed
- related to
-
SERVER-31888 Re-enable periodic no-op writer for all sharding and replication fuzzer test suites
- Closed