-
Type: Task
-
Resolution: Unresolved
-
Priority: Minor - P4
-
None
-
Affects Version/s: None
-
Cluster Scalability
There used to be a case where a write command swallowed the original error code and replaced it with OperationFailed, but we believe that has been fixed in SERVER-33542. This ticket has been left open to track the work to remove the special case for it here.
Original Description
Similarly to SERVER-31730, there are commands that swallow plan executor errors (like InterruptedDueToReplStateChange) and instead return ErrorCodes::OperationFailed. This interferes with mongos retry logic and the retry logic in the jscore and concurrency continuous stepdown suites.
These are the commands I've seen that definitely have this problem, there may be more though:
find,
findAndModify,
distinct,
geoNear
Grepping for "executor error" turns up a few more places where this could be an issue, since it seems like this logic has been copied across a few commands.
- is related to
-
SERVER-33542 Using maxTime() on MongoDB 3.4 and 3.6 does not yield the same error code
- Closed
-
SERVER-31730 PlanExecutor::executePlan() should preserve error code from getNext() failure
- Closed