[SERVER-68922] $natural parser should be stricter (reject NaN, etc) Created: 17/Aug/22  Updated: 29/Oct/23  Resolved: 05/Apr/23

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

Type: Bug Priority: Major - P3
Reporter: David Percy Assignee: Davis Haupt (Inactive)
Resolution: Fixed Votes: 0
Labels: quick-tech-debt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by COMPASS-6703 Investigate changes in SERVER-68922: ... Closed
Documented
is documented by DOCS-16012 [Server] Investigate changes in SERVE... Closed
Related
related to SERVER-77413 Replace old indexHint idl type with t... Backlog
is related to SERVER-68309 Investigate for unsafe narrowing conv... Closed
is related to SERVER-73194 [CQF] Allow hints to go through CQF Closed
is related to SERVER-77075 Define query settings in idl Closed
Assigned Teams:
Query Optimization
Backwards Compatibility: Minor Change
Operating System: ALL
Participants:

 Description   

A $natural hint or sort is supposed to take a direction: +1 or -1. But the parser allows other values, such as 0, NaN, or -0.01. In 5.0 and later we define safeNumberInt() < 0 to mean descending, which means 0, NaN and -0.01 are ascending. In 4.4 and earlier we use the unsafe numberInt(), so whether NaN is ascending or descending depends on the platform.

We should reject all of these inputs with a clear error. We should also consider using the number() < 0 idiom for consistency with index keys and sort patterns.

It looks like this doesn't affect other hints and sorts, because we either validate the SortPattern, or check that the hint matches to an existing index key.



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

Author:

{'name': 'Davis Haupt', 'email': 'davis.haupt@mongodb.com', 'username': 'davish'}

Message: SERVER-68922 reject invalid $natural inputs
Branch: master
https://github.com/mongodb/mongo/commit/6989337f513dcbe867638dc1a32e71f71a31c758

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