GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — [coverage] Conformance findings: STATEMENT-028 · Issue #1012 · databricks/databricks-sql-python

[coverage] Conformance findings: STATEMENT-028 #1012

New issue
Copy link
New issue
Copy link
Open
Open
[coverage] Conformance findings: STATEMENT-028#1012
Copy link

Description

@peco-engineer-bot
peco-engineer-bot
bot
opened on Nov 5, 2026
Issue body actions

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-python. 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-python) is fixed, then flips green as a tripwire.

Findings

  • STATEMENT-028 [thrift]: Thrift backend drops the failed operation's server-reported SQLSTATE: _check_command_not_in_error_or_closed_state raises ServerOperationError from the terminal operation-status payload but never forwards that payload's top-level sqlState, so the error exposes no sql_state — while the kernel backend sets that exact attribute on the same exception class, making SQLSTATE availability depend on which wire protocol delivered the failure
    • failing test: test_failed_operation_error_exposes_server_sql_state (see the coverage PR diff under tests/)

Reproduce & Expected

STATEMENT-028 — Validates that a statement which COMPILES and then FAILS AT RUNTIME on the server raises an error carrying the server-reported SQLSTATE as first-class error metadata -- a dedicated field/accessor on…

Reproduce:

SELECT raise_error('boom')

Expected (per the shared spec):

  • full assertion contract:
result:
- error:
    present: true
- error:
    contains:
    - boom
- error_sql_state:
    present: true
    length: 5
  condition: the terminal operation-status payload carried a SQLSTATE for the failed
    operation
  description: 'The error exposes a 5-character SQLSTATE. Gated on the server actually
    sending one:

    if the terminal payload carries none the driver must NOT invent one, and a surface

    that mandates a SQLSTATE may report its own generic state (e.g. ODBC `HY000`).

    '
- error_sql_state:
    equals_wire_value: true
  condition: the terminal operation-status payload carried a SQLSTATE for the failed
    operation
  description: 'Equal to the operation-level SQLSTATE the protocol blocks below locate
    on the wire

    for this run.

    '
- error_sql_state:
    not_equals: '00000'
  description: 'Never the enclosing status/transport envelope''s success SQLSTATE
    -- that envelope

    reports that the status call succeeded, not how the query failed.

    '
protocol:
  thrift:
  - response_field:
      method: GetOperationStatus
      path: sqlState
      present: true
      occurrence: last
      condition: GetOperationStatus response operationState == ERROR_STATE
  - response_field:
      method: GetOperationStatus
      path: status.statusCode
      equals: SUCCESS_STATUS
      occurrence: last
      condition: GetOperationStatus response operationState == ERROR_STATE
  sea:
  - response_field:
      operation: ExecuteStatement
      path: status.sql_state
      present: true
      occurrence: last
      condition: execute response status.state == FAILED
  - response_field:
      operation: GetStatementStatus
      path: status.sql_state
      present: true
      occurrence: last
      condition: status response status.state == FAILED

Context

  • The behavior was first fixed in a DIFFERENT driver — reference PR: missing errorCode and statusCode on errors (#33) databricks-sql-nodejs#563 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-python; 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/1946

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.