[SERVER-84390] Fix timeseries_predicates.js to actually test what it purports to be testing Created: 21/Dec/23  Updated: 18/Jan/24

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

Type: Bug Priority: Major - P3
Reporter: Irina Yatsenko (Inactive) Assignee: Backlog - Query Integration
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Assigned Teams:
Query Integration
Operating System: ALL
Participants:
Linked BF Score: 5

 Description   

In attempt to cover various data distributions across buckets in a time-series collection the test driver automatically generates 2^N cases for each case of input documents and uses a non-time-series collection as an oracle to check the results.

1. SERVER-71800 made the test somewhat faster (it now takes ~3min in my local runs) but the change wasn't ported to prior releases. Sometimes (BF-30944) it times out.
2. Per the change for SERVER-73697 the test was modified in such a way that, while still running through 2^N variations per input, it stopped distributing the inputs across different buckets.
3. Starting from 5.2 the mixed-type buckets aren't created so we need a failpoint or some other way to force heterogeneous buckets to test that filtering of upgraded time-series is still correct.

In post 5.2 there is no failpoint to create mixed-schema buckets by inserting into the user-facing time-series view. However, we can write directly into the system buckets collection. On the storage side this should set timeseriesBucketsMayHaveMixedSchemaData flag (after SERVER-84531 is fixed).

It also looks like the tests in this file have been extended to cover scenarios that are unrelated to mixed-schema bucketing (e.g. for

{"mt.a": {$size: 1}}

).
These tests should probably find a new home.


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