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

Add integration test to exercise early return branches in ViewShardingCheck::GetResolvedViewIfSharded

    XMLWordPrintableJSON

Details

    • Icon: Task Task
    • Resolution: Won't Fix
    • Icon: Minor - P4 Minor - P4
    • None
    • None
    • None
    • Query
    • Fully Compatible

    Description

      We need to consider whether or not to add an integration test to exercise two early return paths in ViewShardingCheck::getResolvedViewIfSharded().

      The first early return occurs if ViewCatalog::resolveView() encounters an error while resolving a view. We've never seen this happen, and it requires some bad timing/manual manipulation of system.views, but one could imagine the following scenario:

      1. A user performs a query on a view; say, test.view. The aggregation command resolves all of the involved namespaces successfully.
      2. Another user manually modifies test.system.views so that test.view either participates in a cyclical view definition, or exceeds the maximum BSON size.
      3. The thread performing the query reaches aggregation's view sharding check, which then hits the early return path because test.view can no longer be resolved properly.

      The second early return bails depending on the mongod's replica set role and whether or not the collection is sharded. I'm under the impression that we make some very conservative guesses about the sharding state of the collection and we never end up using this early return path.

      Attachments

        Activity

          People

            backlog-server-query Backlog - Query Team (Inactive)
            kyle.suarez@mongodb.com Kyle Suarez
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: