[SERVER-37100] Investigate a way to deal with pre-evaluation errors in optimization agg-fuzzer Created: 12/Sep/18  Updated: 29/Oct/23  Resolved: 02/Oct/18

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: 4.1.4

Type: Improvement Priority: Major - P3
Reporter: David Bradford (Inactive) Assignee: Robert Guo (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-37101 Add optimization mode aggregation (pi... Closed
is depended on by SERVER-36698 Add suite for agg expr fuzzer optimiz... Closed
Related
Backwards Compatibility: Fully Compatible
Sprint: TIG 2018-09-24, STM 2018-10-08
Participants:

 Description   

When running aggregation, the aggregation framework will pre-evaluate some of the arguments. During that pre-evaluation, it may encounter and throw an error. If optimizations are disabled via failpoints, however, the pre-evaluation phase does not happen and the error is not hit, instead the aggregation simply returns no documents.

As a result, when the aggregation fuzzer is run in optimization mode, it frequently hits this discrepancy (one mongod throws an error and another returns 0 documents).

One possible solution from charlie.swanson would be to add context to the error messages hit during pre-evaluation. The fuzzer could then check for that context and validate accordingly.

This ticket is to investigate what it would take to implement that solution (or another solution if appropriate), make any needed changes to the mongo repo and open a ticket to update the aggregation fuzzer.



 Comments   
Comment by Githook User [ 02/Oct/18 ]

Author:

{'name': 'Robert Guo', 'email': 'robert.guo@10gen.com', 'username': 'guoyr'}

Message: SERVER-37100 add context to agg pre-evaluation errors
Branch: master
https://github.com/mongodb/mongo/commit/98cf14e795ec390182286f86edd7cf134325c81f

Comment by Charlie Swanson [ 12/Sep/18 ]

As a more blunt way to fix this, we could also consider it acceptable for one to return 0 documents and the other to return an error - but I'd prefer the solution in the description if it's not too hard engineering-wise. At this point, I don't think it would be.

Comment by David Bradford (Inactive) [ 12/Sep/18 ]

Here is an example of the failure: https://evergreen.mongodb.com/task/mongodb_mongo_master_enterprise_rhel_62_64_bit_aggregation_optimization_fuzzer_patch_626567bcde38521d76834db0c59e1aee62344b69_5b9923622fbabe77fd9660b1_18_09_12_14_32_30

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