-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
None
-
Go Drivers
-
None
-
None
-
None
-
None
-
None
-
None
Context
On sharded topologies, failpoints are applied to only a single mongoS. If the driver is connected to multiple mongoS instances, there's a possibility a different mongoS will be selected for a subsequent command. In that case, the failpoint is effectively ignored, leading to a test failure that is extremely difficult to diagnose.
We should prohibit using failpoints on sharded topologies with an override for those tests that specifically need to use failpoints on sharded topologies.
Definition of done
- Fail a test if SetFailPoint is called and mtest is connected to a sharded topology.
- Add an mtest option that overrides the above behavior, allowing some tests to specifically test with failpoints on sharded topologies if required.
- Prevent running tests that use failpoints on sharded topologies, with a note about why sharded topologies are omitted.
Pitfalls
- We will skip a few tests (about 10 tests based on experimentation) on sharded topologies, which will reduce our test coverage slightly.
- We eventually want to implement GODRIVER-3328, which (if successful) will make this ticket unnecessary. The level-of-effort for GODRIVER-3328 is unclear.
- is related to
-
GODRIVER-3328 mtest should set failpoints on every node in sharded cluster
-
- Backlog
-