-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Server Programmability
Today, almost all users of the Shard API use ShardRemote to execute commands. The exception is certain commands that the config server executes on itself, which uses ShardLocal and the localCatalogClient.
Now that a config-shard can also be an embedded router, we should ensure via the API that only operations that are ClusterRole::ShardServer/ClusteRole::ConfigServer operations (i.e. those created under and managed by the shard-role Service object) are able to use the ShardLocal and localCatalogClient APIs. This will prevent bugs/confusing cases of the form:
- Accept operation on router port, create a router-service opCtx
- That operation uses some API that has the knowledge that the current process is the config server (i.e. refreshSessionsCollectionNow accesses the SessionsCollection, which is SessionsCollectionConfigServer when we are a configShard)
- That API attempts to use the same router-operationContext to do local commands on the config server