-
Type: Bug
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Cluster Scalability
-
Minor Change
-
ALL
-
Sharding EMEA 2022-05-16, Sharding NYC 2023-06-26, Sharding NYC 2023-07-10, Sharding NYC 2023-07-24, Sharding NYC 2023-08-07, Sharding NYC 2023-08-21, Sharding NYC 2023-09-04, Sharding NYC 2023-09-18, Sharding NYC 2023-10-02, Sharding NYC 2023-10-16
-
164
-
3
The deadline is set to Milliseconds::max and the timeout from the operation context is only checked before performing network requests , meaning that the timeout is not respected in case the network request hangs or requires too long.
- has to be done after
-
SERVER-50342 Make version of Shard::runCommand that returns a future
- Open
- is related to
-
SERVER-69979 Refactor Shard::runCommand in terms of the RemoteCommandRunner API
- Closed