[SERVER-86278] Investigate discrepancy between ShardLocal and ShardRemote aggregations Created: 06/Feb/24 Updated: 07/Feb/24 |
|
| Status: | Needs Scheduling |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Jordi Olivares Provencio | Assignee: | Backlog - Catalog and Routing |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||
| Participants: | |||||||||
| Description |
|
The ShardLocal aggregations code ends up calling RSLocalClient. This code ends up overriding the readConcern given to the command. The readConcern given as a result would crash the server if snapshot readConcern is used since the override would swap afterClusterTime with afterOpTime. When processing the request, the server would also add a atClusterTime since it uses snapshot readConcern. This will cause this invariant to get hit since both arguments will be set. |