-
Type:
Bug
-
Resolution: Won't Fix
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
ALL
-
CAR Team 2024-07-22, CAR Team 2024-08-05, CAR Team 2024-08-19, CAR Team 2024-09-02, CAR Team 2024-09-16
-
200
It's possible for lookupNSSbyUUID to fail to find a collection's NSS from its UUID on the donor after a moveCollection .
Example 1:
This breaks the AutoGetCollection* helpers. AutoGetCollection* accept a NamespaceStringOrUUID, and so when a UUID is provided, the first step is to resolve the UUID to a NSS so that the lock can be grabbed.
Essentially because UUID -> NSS resolution can fail, what should've been a StaleConfig (or other sharding staleness error) due to the moveCollection will now manifest as a NamespaceNotFound because we were unable to find the UUID, which is incorrect.
There may be other cases besides AutoGetCollection* where the existing behavior is problematic. See comments and linked BF / tickets for more info and examples. The examples listed below are not exhaustive.
- is depended on by
-
SERVER-91708 Resharding should consider queued index builds waiting for active number of index builds to be below the threshold
-
- Needs Scheduling
-
- related to
-
SERVER-92137 Timeseries inserts may fail with NamespaceNotFound after moveCollection
-
- Closed
-