fix(params): correct DATE and large-number parameter type inference

Two driver-side parameter-binding bugs surfaced by the SEA parity suite
(the kernel binds (value_str, sql_type) faithfully — the defects are in
how DBSQLParameter stringifies/types the value):

- A JS `number` that is whole but outside the INT (i32) range was typed
  INTEGER, so e.g. `1e30` was rejected by the server as
  `invalid INT literal "1e+30"`. inferNumberType now picks the narrowest
  fitting type: INTEGER within i32, BIGINT within the safe-integer range,
  DOUBLE otherwise (and for non-integers).
- A JS `Date` bound with an explicit DATE type was stringified with the
  full ISO-8601 timestamp (`...T00:00:00.000Z`), which the SEA wire
  rejects as a DATE literal ("trailing input"). It now projects the
  calendar date (`yyyy-mm-dd`); the no-explicit-type path still binds a
  Date as a full TIMESTAMP.

Both paths are shared by the Thrift and SEA backends; the changes only
affect values that the previous logic mis-typed (and which the server
rejected), so existing behaviour is preserved. Unit tests added for the
magnitude-based integer inference and the DATE projection.

Signed-off-by: Madhavendra Rathore <madhavendra.rathore@databricks.com>

Author: msrathore-db

lib/DBSQLParameter.ts

@@ -29,6 +29,37 @@ export enum DBSQLParameterType {
   INTERVALDAY = 'INTERVAL DAY',
 }
 
+// 32-bit signed integer bounds — the range of the Spark `INT` type.
+const INT32_MIN = -2147483648;
+const INT32_MAX = 2147483647;
+
+/**
+ * Infer the Spark parameter type for a JS `number` when the caller didn't set
+ * one explicitly.
+ *
+ * A JS `number` is an IEEE-754 double, so a whole-number value can still be far
+ * outside the `INT` range (e.g. `1e30`). Typing such a value as `INTEGER`
+ * makes the server reject it (`invalid INT literal "1e+30"`). Pick the
+ * narrowest type that actually fits:
+ *   - non-integer / non-finite → `DOUBLE`
+ *   - integer within INT (i32) range → `INTEGER`
+ *   - integer within the safe-integer range → `BIGINT`
+ *   - anything larger → `DOUBLE` (can't be represented exactly as an integer
+ *     anyway; callers needing exact 64-bit integers should pass a `bigint`).
+ */
+function inferNumberType(value: number): DBSQLParameterType {
+  if (!Number.isInteger(value)) {
+    return DBSQLParameterType.DOUBLE;
+  }
+  if (value >= INT32_MIN && value <= INT32_MAX) {
+    return DBSQLParameterType.INTEGER;
+  }
+  if (Number.isSafeInteger(value)) {
+    return DBSQLParameterType.BIGINT;
+  }
+  return DBSQLParameterType.DOUBLE;
+}
+
 interface DBSQLParameterOptions {
   type?: DBSQLParameterType;
   value: DBSQLParameterValue;
@@ -78,7 +109,7 @@ export class DBSQLParameter {
     if (typeof this.value === 'number') {
       return new TSparkParameter({
         name,
-        type: wireType ?? (Number.isInteger(this.value) ? DBSQLParameterType.INTEGER : DBSQLParameterType.DOUBLE),
+        type: wireType ?? inferNumberType(this.value),
         value: new TSparkParameterValue({
           stringValue: Number(this.value).toString(),
         }),
@@ -96,11 +127,17 @@ export class DBSQLParameter {
     }
 
     if (this.value instanceof Date) {
+      // A `Date` bound as `DATE` must project a calendar date (`yyyy-mm-dd`),
+      // not a full ISO-8601 timestamp: the SEA wire rejects
+      // `2024-03-14T00:00:00.000Z` as a DATE literal ("trailing input"), and
+      // Thrift accepts the date-only form just as well. Without an explicit
+      // DATE type the value still binds as a TIMESTAMP from the full ISO string.
+      const isDateType = wireType === DBSQLParameterType.DATE;
       return new TSparkParameter({
         name,
         type: wireType ?? DBSQLParameterType.TIMESTAMP,
         value: new TSparkParameterValue({
-          stringValue: this.value.toISOString(),
+          stringValue: isDateType ? this.value.toISOString().slice(0, 10) : this.value.toISOString(),
         }),
       });
     }

tests/unit/DBSQLParameter.test.ts

@@ -124,4 +124,48 @@ describe('DBSQLParameter', () => {
       }),
     );
   });
+
+  it('infers a fitting integer type by magnitude', () => {
+    const cases: Array<[number, DBSQLParameterType, string]> = [
+      // Within INT (i32) range → INTEGER.
+      [42, DBSQLParameterType.INTEGER, '42'],
+      [2147483647, DBSQLParameterType.INTEGER, '2147483647'],
+      [-2147483648, DBSQLParameterType.INTEGER, '-2147483648'],
+      // Beyond i32 but a safe integer → BIGINT (INTEGER would overflow the
+      // server's INT literal parse).
+      [3000000000, DBSQLParameterType.BIGINT, '3000000000'],
+      // Whole-number double outside the safe-integer range → DOUBLE, not
+      // INTEGER. Regression: `Number.isInteger(1e30)` is `true`, so this used
+      // to be typed INTEGER and rejected as `invalid INT literal "1e+30"`.
+      [1e30, DBSQLParameterType.DOUBLE, '1e+30'],
+    ];
+    for (const [value, type, stringValue] of cases) {
+      expect(new DBSQLParameter({ value }).toSparkParameter()).to.deep.equal(
+        new TSparkParameter({ type, value: new TSparkParameterValue({ stringValue }) }),
+      );
+    }
+  });
+
+  it('binds a Date as a calendar date when typed DATE', () => {
+    // Explicit DATE type → date-only `yyyy-mm-dd`. The full ISO timestamp is
+    // rejected by the SEA wire as a DATE literal ("trailing input").
+    expect(
+      new DBSQLParameter({
+        type: DBSQLParameterType.DATE,
+        value: new Date(Date.UTC(2024, 0, 15, 10, 30, 0)),
+      }).toSparkParameter(),
+    ).to.deep.equal(
+      new TSparkParameter({
+        type: DBSQLParameterType.DATE,
+        value: new TSparkParameterValue({ stringValue: '2024-01-15' }),
+      }),
+    );
+    // Without an explicit type a Date still binds as a full TIMESTAMP.
+    expect(new DBSQLParameter({ value: new Date('2023-09-06T03:14:27.843Z') }).toSparkParameter()).to.deep.equal(
+      new TSparkParameter({
+        type: DBSQLParameterType.TIMESTAMP,
+        value: new TSparkParameterValue({ stringValue: '2023-09-06T03:14:27.843Z' }),
+      }),
+    );
+  });
 });