[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:
Backports
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: SERVER-41612 add end-to-end integration tests for FLE
Branch: v4.2
https://github.com/10gen/mongo-enterprise-modules/commit/50406f91fe656ac75e888f03cff43fb20a438ce9

Comment by Githook User [ 09/Jul/19 ]

Author:

{'name': 'Davis Haupt', 'username': 'davish', 'email': 'davis.haupt@mongodb.com'}

Message: SERVER-41612 add end-to-end integration tests for FLE
Branch: master
https://github.com/10gen/mongo-enterprise-modules/commit/116ff63f806bc1d6b899cf30a269ed8816ce6668

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.

Generated at Thu Feb 08 04:58:13 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.