-
Type: Spec Change
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Component/s: Retryability
-
None
-
Needed
-
This came up during testing for Safe Replica Set Reconfig.
During a safe reconfig, the primary will drop snapshots after writing down a new config document. If a read is issued on this node before it updates its snapshot, the server fails with ReadConcernMajorityNotAvailableYet.
The node should eventually be able to update the committed snapshot through heartbeats (2 second interval), so the read will eventually succeed. It seems like we should treat this as a retryable error.
- split to
-
PHPLIB-1295 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Closed
-
JAVA-5224 Make ReadConcernMajorityNotAvailableYet a retryable error
- Ready for Work
-
CXX-2775 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Backlog
-
RUBY-3339 Make ReadConcernMajorityNotAvailableYet a retryable error
- Backlog
-
GODRIVER-3030 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- In Code Review
-
CDRIVER-4752 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Closed
-
CSHARP-4825 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Closed
-
MOTOR-1200 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Closed
-
NODE-5718 Make ReadConcernMajorityNotAvailableYet a retryable error
- Closed
-
PYTHON-4016 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Closed
-
RUST-1786 Consider making ReadConcernMajorityNotAvailableYet a retryable error
- Closed