[SERVER-66271] Consider whether ClusterAggregate::runAggregate should be available on mongoD Created: 05/May/22  Updated: 06/Mar/23

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

Type: Question Priority: Major - P3
Reporter: Bernard Gorman Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-73832 Consider replacing the use of Cluster... Backlog
is related to SERVER-66270 ExpressionContext::inMongos does not ... Open
Assigned Teams:
Query Execution
Sprint: QO 2022-05-30, QO 2022-06-13, QO 2022-06-27
Participants:

 Description   

ClusterAggregate was originally intended to exclusively run on mongoS, with sharded_agg_helpers.cpp intended to be the set of common functions that allowed mongoD to do cross-shard routing. However, as a result of SERVER-45389, ClusterAggregate was incidentally linked into mongoD and ClusterAggregate::runAggregate can now be invoked directly in a mongoD context. This was at best semi-intentional, and gave rise to the issue detailed in SERVER-66270. The only reason that similar problems did not surface earlier is that the only place where ClusterAggregate::runAggregate is actually invoked by mongoD is in the PeriodicShardedIndexConsistencyChecker.

Since we did not consciously make the decision to allow ClusterAggregate::runAggregate to be executed on mongoD, we should consider whether we want this to be the case going forward.



 Comments   
Comment by Brenda Rodriguez [ 12/Jul/22 ]

Moving this to the backlog to be prioritized after the sharding-first catalog project is complete. bernard.gorman@mongodb.com FYI

Comment by Bernard Gorman [ 24/Jun/22 ]

Putting this back in the triage queue because it was Open and in a sprint, but did not have an assignee.

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