[SERVER-34357] produce (or allow to be produced programmatically) a list of top-level aggregation operators for easier declarative testing in sharding Created: 06/Apr/18  Updated: 06/Dec/22  Resolved: 23/Mar/20

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 3.7.3
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Backlog - Query Team (Inactive)
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-46920 Add test cases for all agg stages to ... Closed
Assigned Teams:
Query
Participants:

 Description   

Sharding has several features that operate on all commands (or large swaths of commands):

  • safe secondary reads
  • shard and database versioning
  • causal consistency

For several of these, we have declarative tests that define a test case for every command (from listCommands output) and check that the feature works correctly for that command.

As query moves towards pushing more operations into aggregation, we lose coverage in these tests, since they do not define test cases for every possible initial aggregation stage.

This is especially problematic because these aggregation stages often have special logic ($changeStreams, $listCollections, $currentOp come to mind), so just testing a simple "aggregate" is not enough.



 Comments   
Comment by David Storch [ 23/Mar/20 ]

Thanks for taking a look esha.maharishi! I'm going to change the resolution of this ticket to "Won't Do". Let us know if you run into any trouble using the new aggStageCounters.

Comment by Esha Maharishi (Inactive) [ 17/Mar/20 ]

Hm, I didn't know about that - yes, that seems like it would work! I filed SERVER-46920 to add the test coverage and am closing this ticket as Works as Designed.

Comment by Esha Maharishi (Inactive) [ 06/Apr/18 ]

kyle.suarez, ok. Do you (and the rest of the team) think someone could at least produce a written one-time list as of 4.0, so that we can improve our testing for 4.0?

CC david.storch

Comment by Kyle Suarez [ 06/Apr/18 ]

esha.maharishi – sorry for closing without a comment. I understand that it's a pain point for the Sharding Team during testing, but the Query Team doesn't have any engineering power to do this in the near future. Unless it's directly blocking some critical sharding feature we're not going to schedule it.

If the Sharding Team really wanted this, I suppose you guys could pick it up if you consulted the Query Team regarding the design of how it would be implemented.

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