[SERVER-68856] Investigate why an aggregation running in config server is not able to target other shards Created: 16/Aug/22 Updated: 26/Oct/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Pol Castuera (Inactive) | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | oldshardingemea, shardingemea-qw | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Catalog and Routing
|
| Participants: | |
| Story Points: | 2 |
| Description |
|
When running an aggregation in the config server, the mongo process interface is implemented as a NonShardSvrProcessInterface (LINK), not being able to target other shards. Does it make sense, in order to target other shards, it could implement ShardServerProcessInterface?. The problem is that, while executing aggregation stages in the config server, ShardingState::get(opCtx)->enabled() is set false. It exists the possibility it is coded with this intention. |