Contradictory inequalities break indexHint

Version : 3.12.4

Feature : AQL query optimizer

Description

Hello,

It seems that contradictory inequalities, that always lead to 0 results, break the indexHint mechanism by systematically throwing could not use index hint to serve query.

Query (simplified)

LET some_date = 1738540800000

FOR o IN observations OPTIONS { indexHint: "idx_49081", forceIndexHint: true }
  FILTER o.date_created >= some_date
  FILTER o.date_created <  some_date // inequality #2
  FILTER o.computed.current_name == 'Juniperus oxycedrus L.'
  SORT o.date_created desc
  LIMIT 0, 101
  RETURN o

Indexes

Many, including

idx_49081	computed.current_name	false	10.38%
idx_49054		date_created	false	100.00%

What happens

Forcing the index hint throws error:

Query error: could not use index hint to serve query; {"indexHint":{"forced":true,"lookahead":1,"type":"simple","hint":["idx_49081"]}}

Modifying inequality # 2 to FILTER o.date_created < some_date - 1 still throws error.

Modifying inequality # 2 to FILTER o.date_created < some_date + 1 works.

Asking for an index defined on the field being filtered (here idx_49054, on date_created) also fails.

It seems that the optimizer understands that result will be empty, but throws an error instead of either 1) using the required index, or 2) returning an empty result immediately.

Expected behaviour

Despite the absurdity of the inequalities, one could expect for genericity sake, that the index can still be used, even if it leads to bad performance.

Of course setting forceIndexHintto false throws no error, but this query is generated by some piece of code that needs to force the index hint, notably because of a geo_contains() filter (not shown in this simplified version) that leads to the Geo index always taking precedence despite non-forced indexHint.

We'll fix the generating code, though

Thank you, Mathias