[coverage] Conformance findings: METADATA-035,STATEMENT-023
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- sql, typescript
Research direction
Start with the named xfail tests in the coverage PR diff under tests/, then trace the Thrift implementations of getTables and failed-statement error handling in this connector. Reproduce the nonexistent-table query and the empty tableTypes case; done means both behaviors match the expected SQLSTATE, message, and metadata results and the conformance tests pass.
Written by the indexing model from the issue text.
Description
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-035 [thrift, sea]: getTables treats a non-null empty tableTypes filter ([]) as match-none and returns zero rows, instead of behaving like null and matching all table types
- failing test:
getTables — tableTypes=[] (empty filter) matches ALL table types(see the coverage PR diff undertests/)
- failing test:
- STATEMENT-023 [thrift]: on the thrift path a FAILED-state statement error carries the server message but leaves the structured SQLSTATE unpopulated, so consumers cannot branch on 42P01
- failing test:
failed statement — error exposes server SQLSTATE 42P01 and an informative message(see the coverage PR diff undertests/)
- failing test:
Reproduce & Expected
STATEMENT-023 — Validates that when the server resolves a statement to a FAILED state, the driver surfaces the server's SQLSTATE on the raised error — not just a free-text message. A statement whose SQLSTATE is stable and server-assigned is used: a reference to a table that does not exist, which Databricks reports as TABLE_OR_VIEW_NOT_FOUND with SQLSTATE 42P01. The raised error must expose that SQLSTATE through the driver's standard error surface (ADBC AdbcException.SqlState, JDBC SQLException.getSQLState(), DBAPI error attributes, ODBC SQLGetDiagRec SQLSTATE, etc.). This pins the portable half of the cross-protocol error contract: consumers branch on the status/SQLSTATE pair, so both protocols must populate it identically even though each raises its own natural concrete exception class. The CONCRETE exception TYPE is deliberately NOT asserted — it legitimately differs per protocol and per driver (the reference driver raises DatabricksException on SEA and HiveServer2Exception on Thrift), so requiring one class would encode a driver-internal detail rather than the contract.
Reproduce:
SELECT * FROM nonexistent_catalog_xyz123.nonexistent_schema.nonexistent_table
Expected (per the shared spec):
- full assertion contract:
result:
- error:
sql_state: 42P01
- error:
contains:
- TABLE_OR_VIEW_NOT_FOUND
- not found
- cannot be found
Context
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/adbc-drivers/databricks/pull/604 — 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/1072
- Dominant language
- TypeScript
- Stars
- 36
- Forks
- 50
- Avg merge
- 13h 46m
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from databricks/databricks-sql-nodejs
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
engineer-bot
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
databricks/databricks-sql-nodejs#274 · 1 comment · 1 reaction ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
All issues in databricks/databricks-sql-nodejs
Similar issues
-
S: triage
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
fix(errors): EHOSTUNREACH from a happy-eyeballs connect is reported as a resolver error (STAMP-80) Open
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
snapshot-labs/stamp#666 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
GauravKarakoti/SecureFlow#1070 · 1 comment ·
-
feature:Languages/Translations good first issue ready Web
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
digitalfabrik/integreat-app#4394 ·