[SERVER-32450] Pipeline::createTopLevelOrFacetPipeline incorrectly handles StaleConfigExceptions Created: 21/Dec/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Nicholas Zolnierz | Assignee: | Backlog - Query Optimization |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | QFB, neweng, query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Query Optimization
|
| Participants: |
| Description |
|
While implementing sharded $lookup, I was able to hit a stale config exception on a mongod during pipeline validation which hit this exception handler. In the case of ErrorCodes::StaleConfig, converting back to a status will crash the server here. It's not immediately obvious whether this is reproducible without the sharded $lookup changes, but still seems like a good opportunity for cleanup by changing the interface of Pipeline::parse to throw exceptions instead of returning status and uassertStatusOK at every callsite. |
| Comments |
| Comment by Andy Schwerin [ 24/Dec/17 ] |
|
This might be an appropriate place to leverage the work redbeard0531 is doing to unify Status and DBException. |