[coverage] Conformance findings: METADATA-036,METADATA-037

Start with the coverage PR diff under tests/ and the named failing tests for getTableTypes and the metric-view metadata flag. Trace the driver's table-type enumeration and Thrift OpenSession or SEA CreateSession request paths. Done means the flag is forwarded when enabled, omitted when unset, and neither state includes METRIC_VIEW in the type enumeration.

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

• METADATA-036 [sea]: SEA (kernel) getTableTypes reports a fourth METRIC_VIEW entry in the table-type enumeration; the reference reports exactly {SYSTEM TABLE, TABLE, VIEW} in every metric-view-metadata state
  • failing test: getTableTypes — enumerates the table-type namespace as a distinct type list (see the coverage PR diff under tests/)
• METADATA-037 [thrift]: enableMetricViewMetadata leaks into the table-type enumeration on Thrift: flag ON changes getTableTypes from {TABLE, VIEW} to {TABLE, VIEW, METRIC_VIEW}, but the enumeration must be invariant under the flag (the OpenSession session-conf forwarding itself is correct)
  • failing test: metric-view metadata flag — forwarded as a session conf, type enumeration unchanged (see the coverage PR diff under tests/)
• METADATA-037 [sea]: SEA's flag-ENABLED table-type enumeration carries METRIC_VIEW, which the reference never reports in any flag state (CreateSession session_confs forwarding and absence-when-unset are both correct)
  • failing test: metric-view metadata flag — forwarded as a session conf, type enumeration unchanged (see the coverage PR diff under tests/)
• METADATA-036: SEA (kernel) getTableTypes reports a fourth METRIC_VIEW entry in the table-type enumeration; the reference driver reports exactly {SYSTEM TABLE, TABLE, VIEW} in every metric-view-metadata state, so a client building an object-type picker from the enumeration is offered a filter value the reference never reports
• METADATA-037: enableMetricViewMetadata leaks into the table-type enumeration: on Thrift, enabling the flag changes getTableTypes from {TABLE, VIEW} to {TABLE, VIEW, METRIC_VIEW}. The conf governs server-side metric-view OBJECT visibility in an ordinary table listing and must not alter the driver's supported-type list, which the reference keeps invariant across flag states (the session-conf forwarding itself is correct on both thrift and sea)

Reproduce & Expected

METADATA-036 — Validates the driver can enumerate the TABLE TYPES the server supports, as a dedicated type LIST — one row per supported table type, carrying only the type name and reporting no catalog / schema / ta…

Reproduce:

• Enumerate the supported table types with NO catalog / schema / table filter.
  ODBC: SQLTables(catalog="", schema="", table="", table_type="%") — the "%" must be
  the WHOLE table_type argument and the three name arguments must be present-but-empty
  (or NULL); a non-empty name argument is an ordinary table listing, not an enumeration.

Expected (per the shared spec):

• The table-type enumeration completes successfully
• At least one table type is reported
• TABLE and VIEW are always reported by Databricks. Subset check only — SYSTEM TABLE is also reported (the system UC catalog) and must not fail the assertion.
• METRIC_VIEW is NOT part of the table-type enumeration. The reference driver reports exactly {SYSTEM TABLE, TABLE, VIEW} here, in every metric-view-metadata state, so a driver carrying METRIC_VIEW in a static type list diverges and would hand a client a filter value the reference never reports (databricks-odbc#205). Metric-view objects remain discoverable via a regular table listing (METADATA-037), so this exclusion costs no discoverability.
• Every row carries a non-null, non-empty type name
• No duplicate type rows (the enumeration is a distinct set, not a per-table scan)
• The rows are type entries, not table rows: no catalog / schema / table name is reported for any row. ODBC (5-column SQLTables layout): TABLE_CAT, TABLE_SCHEM and TABLE_NAME are NULL, and REMARKS is a non-null empty string per the ODBC non-null convention. Drivers whose table-type result is a single TABLE_TYPE column satisfy this structurally.

METADATA-037 — Validates the driver's metric-view-metadata switch does two INDEPENDENT things correctly (databricks-odbc#205): 1.

Reproduce:

• Open a session with the driver's metric-view-metadata switch ENABLED, then run the
  table-type enumeration exactly as METADATA-036 does (no catalog / schema / table
  filter; ODBC: SQLTables(catalog="", schema="", table="", table_type="%")). Observe
  both the session-open request on the wire and the enumeration result.
• Repeat with the switch UNSET (driver default) and confirm the conf is absent from the
  session-open request while the enumeration result is unchanged.

Expected (per the shared spec):

• completes without an exception
• [thrift] OpenSession request configuration[spark.sql.thriftserver.metadata.metricview.enabled] == 'true'
• [thrift] OpenSession request configuration[spark.sql.thriftserver.metadata.metricview.enabled] is absent
• [sea] CreateSession request session_confs[spark.sql.thriftserver.metadata.metricview.enabled] == 'true'
• [sea] CreateSession request session_confs[spark.sql.thriftserver.metadata.metricview.enabled] is absent
• full assertion contract:

result:
- no_exception: true
  description: Enabling the flag breaks neither session open nor the enumeration
- type: result_not_contains
  column: TABLE_TYPE
  excluded_values:
  - METRIC_VIEW
  description: "Flag ENABLED \u2014 the table-type ENUMERATION is unchanged: still\
    \ no METRIC_VIEW. The\nflag governs server-side object visibility in a regular\
    \ listing, never the driver's\nsupported-type list (the independence claim of\
    \ databricks-odbc#205).\n"
- type: result_contains
  column: TABLE_TYPE
  expected_values:
  - TABLE
  - VIEW
  description: "Flag ENABLED \u2014 the enumeration still reports the normal types,\
    \ i.e. the flag neither\nadds nor removes entries. Subset check (SYSTEM TABLE\
    \ also appears).\n"
protocol:
  thrift:
  - request_field:
      method: OpenSession
      path: configuration[spark.sql.thriftserver.metadata.metricview.enabled]
      equals: 'true'
    description: "Flag ENABLED \u2014 the driver forwards the server session conf\
      \ in the OpenSession\n`configuration` map, with the truthy spelling the server\
      \ accepts (\"true\"), not\nthe driver's own raw flag string. This is the assertion\
      \ that goes RED on a\ndriver that accepts the flag and then drops it.\n"
  - request_field:
      method: OpenSession
      path: configuration[spark.sql.thriftserver.metadata.metricview.enabled]
      present: false
    label: flag_unset
    description: "Flag UNSET (default OFF) \u2014 the conf is NOT sent at all, leaving\
      \ the server's own\ndefault in force. Asserting ABSENCE, not `equals: \"false\"\
      `: a redundant \"false\"\nwould override a server default rather than defer\
      \ to it.\n"
  sea:
  - request_field:
      operation: CreateSession
      path: session_confs[spark.sql.thriftserver.metadata.metricview.enabled]
      equals: 'true'
    description: "Flag ENABLED \u2014 the SEA counterpart: the CreateSession request's\
      \ session-conf map\ncarries the key with value \"true\".\n"
  - request_field:
      operation: CreateSession
      path: session_confs[spark.sql.thriftserver.metadata.metricview.enabled]
      present: false
    label: flag_unset
    description: "Flag UNSET (default OFF) \u2014 the conf is absent from CreateSession,\
      \ deferring to\nthe server's own default.\n"

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/212 — 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/1165