Details
-
Bug
-
Resolution: Fixed
-
Major - P3
-
6.0.0-rc13, 6.2.0-rc0
-
None
-
None
-
Fully Compatible
-
ALL
-
-
Execution Team 2023-02-06, Execution Team 2023-04-03, Execution Team 2023-05-01, Execution Team 2023-05-15, Execution Team 2023-05-29, Execution Team 2023-06-12, Execution NAMR Team 2023-06-26
-
0
Description
In the linked BF, we have two tests running in parallel: (1) jstests/core/[api_version_test_expression.js|https://github.com/10gen/mongo/blob/master/jstests/core/api_version_test_expression.js] and (2) jstests/core/[api_version_new_50_language_features.js|https://github.com/10gen/mongo/blob/master/jstests/core/api_version_new_50_language_features.js].
(1) successfully creates views with validators on them. Several of these may collide with (2) in a similar way; for example, (1) creates a view "unstableView" with the pipeline:
[{"v": {"$_testApiVersion": {"unstable": true}}}}}]
|
(2) then tries to create a view with apiStrict: true. This view will define a PipelineValidatorFn validatePipeline which is passed into upsertIntoGraph; this validates that the pipeline we're creating doesn't include (among other things) stages marked as unstable. The test failure happens while this view is being created and _viewGraphNeedsRefresh is set to true. At this point, we iterate over views in our view map, and call the same validatePipeline function for apiStrict:true on _all views, including the ones which shouldn't be getting validated.
This wouldn't cause a test failure if we were only returning an error status code; however, it seems that the particular uassert being triggered is not returned as a Status with an error code (which we would handle correctly), but rather thrown as an error which is not caught.
In any case, we shouldn't be applying the apiStrict:true validation for one view to all views in the viewGraph at all.