[SEA-NodeJS] Make queryTimeout a no-op on SEA (stop abusing wait_timeout)

`queryTimeout` was mapped to the kernel's `wait_timeout` (via `query_timeout_secs`
→ `wait_timeout={N}s` + CANCEL). That is semantically wrong: `wait_timeout` is the
server's inline-HOLD window (how long the POST blocks for results, capped 5–50s),
NOT a statement-execution timeout. Mapping queryTimeout there silently caps it at
50s, rejects <5s with HTTP 400, and conflates the inline wait with execution.

Per the option's own JSDoc, `queryTimeout` is "effective only with Compute
clusters; for SQL Warehouses use the STATEMENT_TIMEOUT configuration" — and SEA
targets SQL Warehouses. So make it a clean no-op on the SEA backend: not forwarded
to the kernel (sync directResults path no longer sends `query_timeout_secs`), and
not applied as a client-side deadline (async path). Drop the now-dead
`buildExecuteOptions` param and the unused `numberToInt64` import.

Verified e2e: `queryTimeout: 5` on a ~35s query previously cancelled at ~5s; it now
runs to completion (no-op). directResults CREATE/close/cancel unaffected.

Tests: sync + async paths now assert queryTimeout is NOT forwarded; removed the
obsolete Int64 client-side-deadline test. SEA suite 262 passing; eslint clean.

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

Author: msrathore-db

lib/sea/SeaSessionBackend.ts

@@ -35,7 +35,6 @@ import ParameterError from '../errors/ParameterError';
 import { LogLevel } from '../contracts/IDBSQLLogger';
 import { SeaConnection, SeaNativeExecuteOptions, SeaStatement, SeaNativeAsyncStatement } from './SeaNativeLoader';
 import { decodeNapiKernelError } from './SeaErrorMapping';
-import { numberToInt64 } from '../thrift-backend/ThriftSessionBackend';
 import SeaOperationBackend from './SeaOperationBackend';
 import { buildSeaPositionalParams, buildSeaNamedParams } from './SeaPositionalParams';
 import { seaServerInfoValue } from './SeaServerInfo';
@@ -135,9 +134,9 @@ export default class SeaSessionBackend implements ISessionBackend {
    * Per-statement options forwarded to the kernel `ExecuteOptions`:
    *   - `ordinalParameters` / `namedParameters` → bound params (mutually
    *     exclusive — the kernel binds one placeholder style per statement);
-   *   - `queryTimeout` → enforced client-side by the operation backend's poll
-   *     deadline (the kernel ignores `queryTimeoutSecs` on the async submit
-   *     path), NOT forwarded to the napi options;
+   *   - `queryTimeout` → NO-OP on SEA (SQL Warehouses use `STATEMENT_TIMEOUT`);
+   *     never forwarded to the kernel and never applied as a client-side
+   *     deadline — see the note in `executeStatement`;
    *   - `rowLimit` → `rowLimit` (SEA-only server-side row cap);
    *   - `queryTags` → serialised into the conf overlay's reserved
    *     `query_tags` key (the same wire shape Thrift's `serializeQueryTags`
@@ -183,20 +182,25 @@ export default class SeaSessionBackend implements ISessionBackend {
     //     query, or a still-running `AsyncStatement` (poll/cancel handle) for a
     //     slow one. The handle is server-owned, so a long query stays cancellable
     //     via `op.cancel()` and `close()` is a clean release (no client-side
-    //     drive-to-terminal). `queryTimeoutSecs` IS honoured here (forwarded to
-    //     the napi options below) — note the kernel sends it as `wait_timeout=Ns`
-    //     + CANCEL, so a timeout shorter than the query cancels it (eager error)
-    //     rather than returning the `Running` handle.
+    //     drive-to-terminal). `queryTimeout` is a no-op here (see the note
+    //     below) — it is NOT mapped to the server `wait_timeout`.
     //
     //   - `runAsync: true` — ASYNC. Submit (`wait_timeout=0s`): the server
     //     returns a pending `AsyncStatement` immediately while the query runs;
     //     the backend polls `status()` to terminal in `waitUntilReady()` and
-    //     materialises results via `awaitResult()`. `queryTimeoutSecs` is
-    //     ignored by the kernel on submit, so it is enforced client-side by the
-    //     operation backend's poll-loop deadline instead.
+    //     materialises results via `awaitResult()`. `queryTimeout` is a no-op
+    //     here too.
     const runAsync = options.runAsync ?? false;
-    const queryTimeoutSecs =
-      options.queryTimeout !== undefined ? numberToInt64(options.queryTimeout).toNumber() : undefined;
+    // `queryTimeout` is a NO-OP on the SEA (kernel) backend. It is the JDBC
+    // `setQueryTimeout` knob which — per the option's JSDoc — is effective only
+    // on Compute clusters; SQL Warehouses (what SEA targets) use the
+    // `STATEMENT_TIMEOUT` SQL/session conf instead. We deliberately do NOT map it
+    // to the SEA `wait_timeout` field: `wait_timeout` is the server's inline-hold
+    // window (the time the POST blocks for results, capped 5–50s), NOT a
+    // statement-execution timeout — mapping it there silently caps the timeout at
+    // 50s, rejects <5s with HTTP 400, and conflates the inline wait with
+    // execution. So `queryTimeout` is neither forwarded to the kernel nor used as
+    // a client-side deadline.
 
     if (!runAsync) {
       // DEFAULT — directResults (the Thrift/JDBC model). The kernel's
@@ -208,7 +212,7 @@ export default class SeaSessionBackend implements ISessionBackend {
       // query stays cancellable via `op.cancel()` and `close()` is a clean
       // release (no client-side drive-to-terminal). Fire-and-forget DDL/DML
       // commits because the server runs it inline during the POST.
-      const execOptions = this.buildExecuteOptions(options, queryTimeoutSecs);
+      const execOptions = this.buildExecuteOptions(options);
       let direct: SeaStatement | SeaNativeAsyncStatement;
       try {
         direct =
@@ -231,13 +235,13 @@ export default class SeaSessionBackend implements ISessionBackend {
       // Feature-detect the arm via a type guard: only the Running `AsyncStatement`
       // exposes `awaitResult`; the terminal `Statement` (Completed arm) does not.
       if (isSeaAsyncStatement(direct)) {
-        return new SeaOperationBackend({ asyncStatement: direct, context: this.context, queryTimeoutSecs });
+        return new SeaOperationBackend({ asyncStatement: direct, context: this.context });
       }
-      return new SeaOperationBackend({ statement: direct, context: this.context, queryTimeoutSecs });
+      return new SeaOperationBackend({ statement: direct, context: this.context });
     }
 
-    // Async path: do NOT forward `queryTimeoutSecs` (the kernel ignores it on
-    // submit — `wait_timeout=0s`); it is enforced client-side by the poll loop.
+    // Async path: submit (`wait_timeout=0s`) returns a pending handle the
+    // backend polls. (`queryTimeout` is a no-op on SEA — see the note above.)
     const execOptions = this.buildExecuteOptions(options);
     let asyncStatement;
     try {
@@ -248,16 +252,11 @@ export default class SeaSessionBackend implements ISessionBackend {
     } catch (err) {
       throw this.logAndMapError('executeStatement', err);
     }
-    // `queryTimeout` is enforced client-side by the operation backend's poll
-    // loop: the kernel ignores `queryTimeoutSecs` on the async submit path
-    // (`submitStatement` always sends `wait_timeout=0s`), so we do NOT forward
-    // it to the napi options — passing it there would be a silent no-op.
+    // `queryTimeout` is a no-op on SEA (see the note at the top of this method);
+    // not forwarded to the kernel and not applied as a client-side deadline.
     return new SeaOperationBackend({
       asyncStatement: asyncStatement!,
       context: this.context,
-      // `queryTimeout` is typed `number | bigint | Int64`; `numberToInt64(...).toNumber()`
-      // coerces all three (a bare `Number(int64)` yields NaN — node-int64 has no valueOf).
-      queryTimeoutSecs,
     });
   }
 
@@ -266,10 +265,7 @@ export default class SeaSessionBackend implements ISessionBackend {
    * `ExecuteOptions`, returning `undefined` when nothing is set so the
    * no-options call shape (`executeStatement(sql)`) is preserved.
    */
-  private buildExecuteOptions(
-    options: ExecuteStatementOptions,
-    queryTimeoutSecs?: number,
-  ): SeaNativeExecuteOptions | undefined {
+  private buildExecuteOptions(options: ExecuteStatementOptions): SeaNativeExecuteOptions | undefined {
     // Positional (`?`) and named (`:name`) parameters are mutually exclusive —
     // the kernel binds one placeholder style per statement. Use the SAME error
     // type and message as the Thrift backend (`ThriftSessionBackend`) so a
@@ -287,14 +283,9 @@ export default class SeaSessionBackend implements ISessionBackend {
     if (namedParams !== undefined) {
       execOptions.namedParams = namedParams;
     }
-    // `queryTimeoutSecs` is forwarded only on the SYNC path (the caller passes
-    // it in): the kernel `execute()` consults it as the server statement
-    // timeout. On the async submit path the caller omits it (the kernel ignores
-    // it under `wait_timeout=0s`), so it is enforced client-side by the
-    // operation backend's poll-loop deadline instead (see executeStatement).
-    if (queryTimeoutSecs !== undefined) {
-      execOptions.queryTimeoutSecs = queryTimeoutSecs;
-    }
+    // NB: `queryTimeout` is intentionally NOT forwarded — it is a no-op on SEA
+    // (SQL Warehouses use `STATEMENT_TIMEOUT`; mapping it to `wait_timeout` would
+    // abuse the inline-hold window). See the note in `executeStatement`.
     if (options.rowLimit !== undefined) {
       execOptions.rowLimit = Number(options.rowLimit);
     }

tests/unit/sea/execution.test.ts

@@ -14,7 +14,6 @@
 
 import { expect } from 'chai';
 import sinon from 'sinon';
-import Int64 from 'node-int64';
 import SeaBackend from '../../../lib/sea/SeaBackend';
 import SeaSessionBackend from '../../../lib/sea/SeaSessionBackend';
 import SeaOperationBackend from '../../../lib/sea/SeaOperationBackend';
@@ -650,46 +649,23 @@ describe('SeaSessionBackend', () => {
     expect((thrown as Error).message).to.equal('Driver does not support both ordinal and named parameters.');
   });
 
-  it('executeStatement (sync default) DOES forward queryTimeout to the napi options', async () => {
+  it('executeStatement (sync default) does NOT forward queryTimeout — no-op on SEA', async () => {
     const connection = new FakeNativeConnection();
     const session = makeSession(connection);
     await session.executeStatement('SELECT 1', { queryTimeout: 30 });
-    // Sync path: the kernel `execute()` honours queryTimeoutSecs (server
-    // statement timeout), so the backend forwards it onto the napi options.
-    expect((connection.lastOptions as { queryTimeoutSecs?: number } | undefined)?.queryTimeoutSecs).to.equal(30);
+    // queryTimeout is a no-op on SEA (SQL Warehouses use STATEMENT_TIMEOUT). It
+    // must NOT be mapped to the kernel's `wait_timeout` (the inline-hold window),
+    // so nothing is forwarded onto the napi options.
+    expect((connection.lastOptions as { queryTimeoutSecs?: number } | undefined)?.queryTimeoutSecs).to.equal(undefined);
   });
 
-  it('executeStatement (runAsync: true) does NOT forward queryTimeout to submit (kernel ignores it; enforced client-side)', async () => {
+  it('executeStatement (runAsync: true) does NOT forward queryTimeout — no-op on SEA', async () => {
     const connection = new FakeNativeConnection();
     const session = makeSession(connection);
     await session.executeStatement('SELECT 1', { queryTimeout: 30, runAsync: true });
-    // Async submit path: the kernel ignores queryTimeoutSecs under
-    // `wait_timeout=0s`, so it's enforced client-side by the poll deadline
-    // instead — never forwarded to the napi options.
     expect((connection.lastOptions as { queryTimeoutSecs?: number } | undefined)?.queryTimeoutSecs).to.equal(undefined);
   });
 
-  it('coerces an Int64 queryTimeout into the client-side deadline on the async path (not NaN)', async function int64Timeout() {
-    // Regression: `Number(new Int64(...))` yields NaN (node-int64 has no valueOf),
-    // which would silently disable the deadline. The backend must coerce via
-    // numberToInt64(...).toNumber() so an Int64 queryTimeout still bounds the poll.
-    // Exercised on the async path, where the client-side poll deadline applies.
-    // eslint-disable-next-line no-invalid-this
-    this.timeout(5000);
-    const connection = new FakeNativeConnection();
-    connection.submitStatusValue = 'Running'; // never reaches a terminal state
-    const session = makeSession(connection);
-    const op = await session.executeStatement('SELECT 1', { queryTimeout: new Int64(1), runAsync: true });
-    let thrown: unknown;
-    try {
-      await op.waitUntilReady();
-    } catch (err) {
-      thrown = err;
-    }
-    expect(thrown, 'Int64(1) timeout must fire — NaN would poll forever').to.be.instanceOf(OperationStateError);
-    expect((thrown as OperationStateError).errorCode).to.equal(OperationStateErrorCode.Timeout);
-  });
-
   it('executeStatement forwards rowLimit', async () => {
     const connection = new FakeNativeConnection();
     const session = makeSession(connection);