[SERVER-41612] Add integration tests for passing larger/more complex pipelines to mongocryptd Created: 10/Jun/19 Updated: 29/Oct/23 Resolved: 09/Jul/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.0-rc3, 4.3.1 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Charlie Swanson | Assignee: | Davis Haupt (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Backport Requested: |
v4.2
|
||||
| Sprint: | Query 2019-07-01, Query 2019-07-15 | ||||
| Participants: | |||||
| Description |
|
We should add tests with large and complex aggregation pipelines, including large and complex expression trees. This will help ensure that the visitors are correctly maintaining state as we expect them to be. Ideally we will also construct test cases that are closer to how we think customers are going to be querying with mongocryptd, mixing many language features at once. |
| Comments |
| Comment by Githook User [ 09/Jul/19 ] |
|
Author: {'name': 'Davis Haupt', 'email': 'davis.haupt@mongodb.com', 'username': 'davish'}Message: |
| Comment by Githook User [ 09/Jul/19 ] |
|
Author: {'name': 'Davis Haupt', 'username': 'davish', 'email': 'davis.haupt@mongodb.com'}Message: |
| Comment by Davis Haupt (Inactive) [ 28/Jun/19 ] |
|
Code review URL: https://mongodbcr.appspot.com/487990003/ |
| Comment by Jacob Evans [ 17/Jun/19 ] |
|
That's a great summary. I think we shouldn't bother targeting the integration tests to particular aggregation expressions or stages and instead blackbox them. We've already tested the parts we know are risky. We need a broader confidence that arbitrary combinations of language features will cause something sensible to occur. |
| Comment by Charlie Swanson [ 17/Jun/19 ] |
|
Idea came from jacob.evans so Jacob should chime in if he wants to expand/clarify further. I think this means that most of our existing tests are targeted at a single expression or two and we don't have many of larger pipelines or more complex queries involving multiple encrypted paths. I think the value we'd get here is particularly for complex expression trees where managing the state of the stack while visiting is manual and error-prone. Having coverage of very deep visitation stacks with numerous subtrees of different types would build our confidence in its correctness. I haven't done enough research to really know what's highest value here so I've just given a generic description. |
| Comment by David Storch [ 17/Jun/19 ] |
|
charlie.swanson, can you add a description to this ticket? As written, I don't know what test coverage we would add that we don't have already. |