-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Query Execution, Sharding
-
Sharding EMEA
-
Fully Compatible
-
ALL
-
Sharding EMEA 2023-03-20, Sharding EMEA 2023-04-03, Sharding EMEA 2023-04-17, Sharding EMEA 2023-05-01, QE 2023-08-07, QE 2023-08-21
When the attachCursorToPipeline method gets to perform routing and it discovers that the collection is UNSHARDED, it will attempt to take the optimised path, establishing cursors locally, though DBDirectClient, instead of making a remote call.
In order to do this, it sets the expected state of the collection correctly on the OpCtx, and then makes a call, which eventually will enter in the shard role. Since this call will already ensure that the cursors are established on the right shard, by virtue of entering the shard role and the checks that this involves, it is unnecessary (and wrong by itself) to call checkOnPrimaryShardForDb, because that check can be invalid as soon as that function returns.
- depends on
-
SERVER-75643 Not all paths of AutoGetCollectionForReadLockFreePITCatalog check for DBVersion
- Closed
-
SERVER-76937 Investigate failing $unionWith tests when `checkOnPrimaryShardForDb` is removed
- Closed