Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-83917

Require by API contract that all ShardLocal/localCatalogClient/config-shard writes have Shard-Service OperationContexts

    • 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

            Assignee:
            Unassigned Unassigned
            Reporter:
            george.wangensteen@mongodb.com George Wangensteen
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: