[SERVER-26861] Add integration test to exercise early return branches in ViewShardingCheck::GetResolvedViewIfSharded Created: 01/Nov/16  Updated: 06/Dec/22  Resolved: 14/Nov/16

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Minor - P4
Reporter: Kyle Suarez Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Fix Votes: 0
Labels: read-only-views
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-25599 Additional tests for views on sharded... Closed
Assigned Teams:
Query
Backwards Compatibility: Fully Compatible
Participants:

 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.


Generated at Thu Feb 08 04:13:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.