You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SimplifyComparisonArithmetics optimization incorrectly applies to queries like FROM test | WHERE int - 1 < 9223372036854775807" (That's Long.MAX_VALUE, to save your eyes). The optimization's tryFolding method expects that if the folding has an error, it will throw an appropriate exception, which the optimization then catches and simply returns the unoptimized input expression. However, ESQL doesn't throw from folding, so this check never applies. Instead, we get back a Literal with a null value. We can't just check for a null value, because the warning about the error will already be on the query at that point, even if we then don't apply the optimization, so it's not a trivial fix.
Steps to Reproduce
PUT http://localhost:9200/test
content-type: application/json
{
"mappings": {
"properties": {
"float": {"type": "float"},
"int": {"type": "integer"},
"double": {"type": "double"}
}
}
}
PUT http://localhost:9200/test/_doc/1
content-type: application/json
{
"int": "11",
"float": "3.14",
"double": "42.42"
}
POST http://localhost:9200/_query?format=txt
content-type: application/json
{
"version": "2024.04.01",
"query": "FROM test | WHERE int < 9223372036854775807 + 1"
}
Logs (if relevant)
No response
The text was updated successfully, but these errors were encountered:
Elasticsearch Version
main
Installed Plugins
No response
Java Version
bundled
OS Version
n/a
Problem Description
The
SimplifyComparisonArithmetics
optimization incorrectly applies to queries likeFROM test | WHERE int - 1 < 9223372036854775807"
(That's Long.MAX_VALUE, to save your eyes). The optimization'stryFolding
method expects that if the folding has an error, it will throw an appropriate exception, which the optimization then catches and simply returns the unoptimized input expression. However, ESQL doesn't throw from folding, so this check never applies. Instead, we get back aLiteral
with a null value. We can't just check for a null value, because the warning about the error will already be on the query at that point, even if we then don't apply the optimization, so it's not a trivial fix.Steps to Reproduce
Logs (if relevant)
No response
The text was updated successfully, but these errors were encountered: