Statement.setQueryTimeout not honored on DatabaseMetaData calls (getTables runs past timeout without aborting) #1569

Summary

databricks-jdbc does not honor Statement.setQueryTimeout(int) on DatabaseMetaData calls: a metadata fetch (e.g. getTables()) whose underlying GetOperationStatus polling is delayed past the configured query timeout runs to completion instead of aborting with a timeout error.

Environment

• driver: databricks-jdbc (OSS) 3.4.x, usethriftclient=1 (Thrift)
• direct results disabled (EnableDirectResults=0) so metadata resolves via GetOperationStatus polling

Behavior

With a proxy scenario that delays GetOperationStatus by ~65s and a client Statement.setQueryTimeout(5):

try (Statement st = c.createStatement()) {
  st.setQueryTimeout(5);                 // 5-second client timeout
  ResultSet rs = c.getMetaData().getTables(catalog, schema, "%", null);
  while (rs.next()) { /* drain */ }       // ran ~65s, then returned normally
}

The call blocked for the full ~65s scenario delay and returned normally — no SQLException/timeout was thrown. The 5-second query timeout had no effect on the metadata operation.

Expected

getTables() (and other DatabaseMetaData operations) should honor the statement query timeout and abort with a timeout/cancellation SQLException once it elapses — the same way Statement.executeQuery(...) does. (This is what the cross-driver spec METADATA-030 "Network Timeout During Metadata Fetch" asserts; C# ADBC aborts within its configured timeout.)

Repro

Reproduced via the cross-driver proxy test harness (databricks-driver-test), spec case METADATA-030, using the statement_timeout scenario (65s delay on GetOperationStatus). Committed as an xfail tripwire (status: jdbc.thrift: bug) that asserts the current no-timeout behavior and will flip to the real timeout assertion once fixed.

Impact

An application that sets a query timeout to bound metadata calls has no protection — a slow/hung metadata request cannot be aborted client-side and blocks for the full server/transport timeout.