[coverage] Conformance findings: TRANSACTION-021

Start with the xfail test named “TRANSACTION-021 — driver bug: isolation metadata advertises no supported level” in the coverage PR under tests, then trace the Node.js session getInfo handling for thrift and SEA. Done means codes 26 and 72 return truthful isolation metadata consistent with the supported transaction level, allowing the xfail test to turn green.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-nodejs. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-sql-nodejs) is fixed, then flips green as a tripwire.

Findings

• TRANSACTION-021 [thrift]: getInfo(CLI_DEFAULT_TXN_ISOLATION=26) and getInfo(SQL_TXN_ISOLATION_OPTION=72) both error on thrift: the driver keeps no capability info table and forwards isolation info codes to the server, which does not answer them, so it advertises no transaction-isolation support while Delta runs serializable-class transactions (same under-reporting class as databricks-odbc#137)
  • failing test: TRANSACTION-021 — driver bug: isolation metadata advertises no supported level [xfail] (see the coverage PR diff under tests/)
• TRANSACTION-021 [sea]: getInfo(CLI_DEFAULT_TXN_ISOLATION=26) and getInfo(SQL_TXN_ISOLATION_OPTION=72) both error on the SEA kernel path too: no driver-side capability info table, so the isolation codes are forwarded to a server that answers only CLI_SERVER_NAME/CLI_DBMS_NAME/CLI_DBMS_VER, leaving isolation capability unadvertised
  • failing test: TRANSACTION-021 — driver bug: isolation metadata advertises no supported level [xfail] (see the coverage PR diff under tests/)
• TRANSACTION-021: getInfo(CLI_DEFAULT_TXN_ISOLATION=26) and getInfo(SQL_TXN_ISOLATION_OPTION=72) both error on thrift and sea: the driver keeps no capability info table and forwards isolation info codes to the server, which does not answer them, so it advertises no transaction-isolation support while Delta runs serializable-class transactions (same under-reporting class as databricks-odbc#137)

Reproduce & Expected

TRANSACTION-021 — Verify the driver's ISOLATION METADATA truthfully advertises the level it actually supports, and agrees with the connection attribute asserted by TRANSACTION-013/014.

Reproduce:

• Read the driver's DEFAULT isolation level from its metadata surface (ODBC:
  SQLGetInfo(SQL_DEFAULT_TXN_ISOLATION); JDBC:
  DatabaseMetaData.getDefaultTransactionIsolation(); Node.js:
  session.getInfo(CLI_DEFAULT_TXN_ISOLATION)).
• Read the SUPPORTED-levels capability (ODBC: SQLGetInfo(SQL_TXN_ISOLATION_OPTION) mask;
  JDBC: supportsTransactionIsolationLevel(level) probed per level).

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/169 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-nodejs; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1174