[ESQL] Fix parsing of large magnitude negative numbers (#110665)

Resolves #104323

This fixes and adds tests for the first of the two bullets in the linked
issue.  `ExpressionBuilder#visitIntegerValue` will attempt to parse a
string as an integral value, and return a Literal of the appropriate
type.  The actual parsing happens in `StringUtils#parseIntegral`.  That
function has special handling for values that are larger than
`Long.MAX_VALUE` where it attempts to turn them into unsigned longs, and
if the number is still out of range, throw `InvalidArgumentException`. 
`ExpressionBuilder` catches that `InvalidArgumentException` and tries to
parse a `double` instead.  If, on the other hand, the value is smaller
than `Long.MIN_VALUE`, `StringUtils` never enters the unsigned long path
and just calls `intValueExact`, which throws `ArithmeticException`. 
This PR solves the issue by catching that `ArithmeticException` and
rethrowing it as an `InvalidArgumentException`.

docs/changelog/110665.yaml

@@ -0,0 +1,6 @@
+pr: 110665
+summary: "[ESQL] Fix parsing of large magnitude negative numbers"
+area: ES|QL
+type: bug
+issues:
+ - 104323

x-pack/plugin/esql-core/src/main/java/org/elasticsearch/xpack/esql/core/util/StringUtils.java

@@ -354,6 +354,9 @@ public static Number parseIntegral(String string) throws InvalidArgumentExceptio
             }
             return bi;
         }
+        if (bi.compareTo(BigInteger.valueOf(Long.MIN_VALUE)) < 0) {
+            throw new InvalidArgumentException("Magnitude of negative number [{}] is too large", string);
+        }
         // try to downsize to int if possible (since that's the most common type)
         if (bi.intValue() == bi.longValue()) { // ternary operator would always promote to Long
             return bi.intValueExact();

x-pack/plugin/esql/qa/testFixtures/src/main/resources/floats.csv-spec

@@ -1,4 +1,11 @@
 // Floating point types-specific tests
+parseLargeMagnitudeValues
+required_capability: fix_parsing_large_negative_numbers
+row a = 92233720368547758090, b = -9223372036854775809;
+
+a:double              | b:double
+9.223372036854776E+19 | -9.223372036854776E+18
+;
 
 inDouble
 from employees | keep emp_no, height, height.float, height.half_float, height.scaled_float | where height in (2.03, 2.0299999713897705, 2.029296875, 2.0300000000000002) | sort emp_no;

x-pack/plugin/esql/src/main/java/org/elasticsearch/xpack/esql/action/EsqlCapabilities.java

@@ -127,7 +127,13 @@ public enum Cap {
         /**
          * Fix for union-types when aggregating over an inline conversion with conversion function. Done in #110652.
          */
-        UNION_TYPES_INLINE_FIX;
+        UNION_TYPES_INLINE_FIX,
+
+        /**
+         * Fix a parsing issue where numbers below Long.MIN_VALUE threw an exception instead of parsing as doubles.
+         * see <a href="https://github.com/elastic/elasticsearch/issues/104323"> Parsing large numbers is inconsistent #104323 </a>
+         */
+        FIX_PARSING_LARGE_NEGATIVE_NUMBERS;
 
         private final boolean snapshotOnly;
 

x-pack/plugin/esql/src/test/java/org/elasticsearch/xpack/esql/parser/StatementParserTests.java

@@ -105,6 +105,17 @@ public void testRowCommandHugeInt() {
         );
     }
 
+    public void testRowCommandHugeNegativeInt() {
+        assertEquals(
+            new Row(EMPTY, List.of(new Alias(EMPTY, "c", literalDouble(-92233720368547758080d)))),
+            statement("row c = -92233720368547758080")
+        );
+        assertEquals(
+            new Row(EMPTY, List.of(new Alias(EMPTY, "c", literalDouble(-18446744073709551616d)))),
+            statement("row c = -18446744073709551616")
+        );
+    }
+
     public void testRowCommandDouble() {
         assertEquals(new Row(EMPTY, List.of(new Alias(EMPTY, "c", literalDouble(1.0)))), statement("row c = 1.0"));
     }