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

LookupQuerySettingsForFind should not be checking the node's sharding recovery state

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 7.3.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • ALL
    • QE 2023-12-11, QE 2023-12-25, QE 2024-01-08, QE 2024-01-22

      As part of SERVER-77079, the lookupQuerySettingsForFind was made to rely on the intialisation status of sharding in order to decide from where to pick up the query settings for a find.

       

      Instead of relying on ShardingState API, we should check if the request comes from the internal Client. There are already similar checks throughout the codebase, such as:

      bool isInternalClient(OperationContext* opCtx) {
          return opCtx->getClient()->session() && opCtx->getClient()->isInternalClient();
      } 

      We should do the same as part of this ticket.

       

      Apart from that we should prioritize the IDHACK check, before anything else. This would speed up some of the industry workloads which run IDHACK queries, by not doing any unnecessary work (such as ShardingState check). (see screenshot)

      We should also put the serializationContext, right before the lookup call

      auto serializationContext = parsedFind.findCommandRequest->getSerializationContext(); 

            Assignee:
            catalin.sumanaru@mongodb.com Catalin Sumanaru
            Reporter:
            kaloian.manassiev@mongodb.com Kaloian Manassiev
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: