-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
ALL
-
(copied to CRM)
-
2
-
🟦 Shard Catalog
-
None
-
None
-
None
-
None
-
None
-
None
Currently, the direct shard operation checks allow operations against shard local namespaces. In admin, local, and config databases, I think this makes sense since these collections would be inaccessible via mongos.
For system collections in user databases, though, I don't think this is safe. This would allow customers to access things like db.system.views bypassing the shard versioning protocol which could end up not finding the collection in the presence of a concurrent movePrimary.
An argument could also be made that isNamespaceAlwaysUntracked is more accurate for the config collections since the globally unique but unsharded collections (like config.collections, etc) would be safe to access via direct connection.