[SERVER-36403] Cluster aggregation error message should indicate which shard(s) raised an error Created: 01/Aug/18 Updated: 29/Oct/23 Resolved: 13/Dec/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Diagnostics |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.7 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Kyle Suarez | Assignee: | Vlad Rachev (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Query 2018-12-17, Query 2018-12-31 |
| Participants: |
| Description |
|
When a sharded aggregation throws, we don't report from where in the cluster the error was generated. To test this, I wrote a simple $assert stage that always throws.
The error message format is the same if I force an assertion in the merger part:
We suspect the AsyncResultsMerger converts the AsyncRequestsSender::Response objects from each shard into a status and immediately throws if it's non-OK. However, this is losing important information; we could indicate from which shard the error occurred. It also hides any other errors that might have been collected. This has implications for the improved $out project, as a failing sharded $out would not indicate from where the failures occurred, making diagnosis harder. |
| Comments |
| Comment by Githook User [ 13/Dec/18 ] | ||||||||||||||||||||||||||||
|
Author: {'username': 'vrachev', 'email': 'vlad.rachev@mongodb.com', 'name': 'vrachev'}Message: | ||||||||||||||||||||||||||||
| Comment by Githook User [ 13/Dec/18 ] | ||||||||||||||||||||||||||||
|
Author: {'username': 'vrachev', 'email': 'vlad.rachev@mongodb.com', 'name': 'vrachev'}Message: | ||||||||||||||||||||||||||||
| Comment by Kyle Suarez [ 03/Aug/18 ] | ||||||||||||||||||||||||||||
|
For reference, commands like createIndexes have responses like
which are a little more friendly. So we should keep that format in mind when designing this one. | ||||||||||||||||||||||||||||
| Comment by Kyle Suarez [ 01/Aug/18 ] | ||||||||||||||||||||||||||||
|
Throwing into Query Team triage queue to debate whether or not we should do this as part of the $out project. |