- It should be clear from the application log whether timeoutMS was applied for operation execution and why. If timeoutMS value was inherited, then from which level.
- It should be clear on which exact stage the timeout triggered while executing an operation (reading/writing to socket, serializing/deserializing the message, maxTimeMS…).
- If the operation was retried and then timed out, it should be clear from the log, how many times it retried before the timeout.
- If the timeout occurred due to maxTimeMS, we would like to know which exact command triggered that. What was the estimation of maxTimeMS used for the command. How it was estimated, what were the values of network RTT, remaining timeoutMS, percentile
- For cursor timeout, we need to know whether the timeoutMode was set and to each value (CURSOR_LIFETIME or ITERATION)
- related to
-
DRIVERS-1204 Easier debugging with standardized logging
- In Progress
- split to
-
CSHARP-4489 Log timeoutMS at the operation level
- Blocked
-
CXX-2641 Log timeoutMS at the operation level
- Blocked
-
GODRIVER-2740 Log timeoutMS at the operation level
- Blocked
-
JAVA-4857 Log timeoutMS at the operation level
- Blocked
-
MOTOR-1088 Log timeoutMS at the operation level
- Blocked
-
NODE-5001 Log timeoutMS at the operation level
- Blocked
-
PHPLIB-1069 Log timeoutMS at the operation level
- Blocked
-
PYTHON-3578 Log timeoutMS at the operation level
- Blocked
-
RUBY-3210 Log timeoutMS at the operation level
- Blocked
-
RUST-1579 Log timeoutMS at the operation level
- Blocked
-
CDRIVER-4560 Log timeoutMS at the operation level
- In Progress