[SERVER-61389] Fuzzer does not tolerate failures during multiplanning in $expr Created: 10/Nov/21  Updated: 20/Jan/22  Resolved: 20/Jan/22

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

Type: Bug Priority: Major - P3
Reporter: Jennifer Peshansky (Inactive) Assignee: Jennifer Peshansky (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-62345 Consider re-evaluating fuzzer testing... Closed
Operating System: ALL
Sprint: QE 2021-11-29, QE 2021-12-13, QE 2021-12-27, QE 2022-01-10, QE 2022-01-24
Participants:
Linked BF Score: 15

 Description   

Occasionally, during multiplanning, a $expr will fail nondeterministically during execution of the candidate plans. In the classic engine, we used ExprMatchExpressionMatchesReturnsFalseOnException as a failpoint to deal with these types of errors. However, since SBE cannot easily simulate a try/catch, we decided in SERVER-56152 to instead relax the fuzzers to handle these types of errors.

In agg_compare_results.js, we relax the fuzzers by checking if both sides used SBE, and if there was a failure in a $expr, we ignore it. However, the way we check if both sides used SBE is to examine the explain output. In some cases, such as BF-23057, the failure happens before the explain output has a chance to be generated. Therefore, it is not caught that both sides are using SBE, and the failure is not ignored by the fuzzer.

SERVER-60848, currently in-progress, will add logging and easier ways to check if SBE was used in a particular query. I propose that, rather than examining the explain output to check if both sides used SBE, we simply modify the check to access this information more directly, presumably checking a value that will be set/created in SERVER-60848.

However, there has been a lot of discussion surrounding this BF, and I am open to discussion and alternative approaches to this ticket.



 Comments   
Comment by Jennifer Peshansky (Inactive) [ 20/Jan/22 ]

The Query Testing focus group filed TIG-3771, "Don't consider "one side errors" to be a failure." After that ticket goes in, this ticket will be solved as well. I am closing this as Won't Do and marking the BF as depending on TIG-3771.

Comment by Jennifer Peshansky (Inactive) [ 10/Nov/21 ]

Due to my proposal that this ticket use information that will be recorded and logged by SERVER-60848, I am marking this as depending on that ticket for now. However, I'm open to discussing alternative approaches to this ticket.

Generated at Thu Feb 08 05:52:18 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.