[coverage] Conformance findings: TRANSACTION-021

Beginne mit dem xfail-Test namens „TRANSACTION-021 — driver bug: isolation metadata advertises no supported level“ im Coverage-PR unter tests und verfolge dann die Node.js-Session-getInfo-Behandlung für thrift und SEA. Erledigt ist die Aufgabe, wenn die Codes 26 und 72 wahrheitsgemäße Isolationsmetadaten zurückgeben, die mit der unterstützten Transaktionsebene übereinstimmen, sodass der xfail-Test grün wird.

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