[SERVER-63902] Natural hints no longer work on TS collections when featureFlagTimeseriesMetricIndexes is enabled Created: 23/Feb/22  Updated: 29/Oct/23  Resolved: 04/Apr/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 5.3.0-rc0
Fix Version/s: 6.0.0-rc0

Type: Bug Priority: Major - P3
Reporter: Michael Gargiulo Assignee: David Percy
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
causes SERVER-65393 tassert in createBucketsSpecFromTimes... Closed
causes SERVER-67648 [v6.0] Tag timeseries_delete_hint.js ... Closed
is caused by SERVER-58716 Allow finds with hints using index sp... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:
  1. Create a Timeseries Collection on 5.3 rc0
  2. Run a query with a nautral hint: find().hint({$natural: 1})
  3. Observe error: "error processing query: ns=test.system.buckets.Collection0Tree: $and\nSort: {}\nProj: {}\nCollation: { locale: \"simple\" }

    \n planner returned error :: caused by :: hint provided does not correspond to an existing index"

Sprint: QO 2022-04-04, QO 2022-04-18
Participants:

 Description   

Hinting $natural on a Timeseries collection no longer works. It appears a recent commit may have broke this functionality. Hinting $natural should always correspond to the clustered index which is built at collection create for a Timeseries collection and all the versions tested below show the clustered index as true in listCollections which is expected, yet the error observed in 5.3 rc0 and latest, 6.0.0-alpha-8-gaba3de6 refers to no index being created

Testing the above steps on 5.2 correctly work as expected and do not produce an error. However, testing on the latest and 5.3 rc0 produces the error. The offending commit seems to have been introduced sometime between 5.2 and 5.3 rc0

Once we correct the issue we should add a test for this case



 Comments   
Comment by Githook User [ 04/Apr/22 ]

Author:

{'name': 'David Percy', 'email': 'david.percy@mongodb.com', 'username': 'dpercy'}

Message: SERVER-63902 Fix $natural hint on time-series collections
Branch: master
https://github.com/mongodb/mongo/commit/7ecd542de5c542c27856032c219a06900778ea3a

Comment by Kyle Suarez [ 23/Feb/22 ]

I also edited the ticket title to make that more clear.

Comment by David Percy [ 23/Feb/22 ]

The feature flag is now disabled on 5.3 (https://github.com/10gen/mongo/commit/687a404519f8c83e494aa3523aed7ef9d0784bff), and I confirmed that this bug no longer appears there, so I think we can lower the priority.

Comment by David Percy [ 23/Feb/22 ]

Looks like the problem is that ResolvedView::asExpandedViewAggregation calls timeseries::createBucketsIndexSpecFromTimeseriesIndexSpec on {$natural: 1}: https://github.com/10gen/mongo/blob/5d99bcaa999e8ca595e36642bdd174abe6986929/src/mongo/db/views/resolved_view.cpp#L189

{$natural: 1} is a valid hint but not a valid index spec. timeseries::createBucketsIndexSpecFromTimeseriesIndexSpec expects an index spec, so it mistranslates {$natural: 1} to {control.min.$natural: 1, control.max.$natural: 1}.

Comment by David Percy [ 23/Feb/22 ]

It looks like this only reproduces when featureFlagTimeseriesMetricIndexes is enabled. The flag is disabled on master (as of https://github.com/10gen/mongo/commit/239052f6e878dcf0892a8ae33b9e69c30a6ffc6d) and soon will be disabled on 5.3.

Comment by Louis Williams [ 23/Feb/22 ]

When I reproduce on 5.3, the `hintObj` on this line in the query planner is equal to:

(gdb) p hintObj
$8 = owned BSONObj 57 bytes @ 0x7fffc3829028 = {
  [control.min.$natural] = 1,
  [control.max.$natural] = 1

So it seems like we're not recognizing the hint as $natural and trying to convert it to an index hint.

On master, this works correctly:

(gdb) p hintObj
$7 = owned BSONObj 19 bytes @ 0x7fffca6da208 = {
  [$natural] = 1
}

Comment by Louis Williams [ 23/Feb/22 ]

Strangely enough this does not reproduce on master.

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