[coverage] Conformance findings: STATEMENT-028

Ouverte Adaptée aux débutants
#1,012 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
backend, databases

Piste de recherche

Commencez par _check_command_not_in_error_or_closed_state et le test en échec test_failed_operation_error_exposes_server_sql_state dans le diff de la PR de couverture sous tests/. Suivez le traitement de la charge utile de l’état de l’opération terminale et l’endroit où ServerOperationError est levée. Le travail est terminé lorsque l’erreur expose le SQLSTATE communiqué par le serveur si la charge utile en contient un, et que le test nommé réussit.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
236
Forks
162
Merge moyen
13 h 13 min
PR mergées (30 j)
23

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de databricks/databricks-sql-python

Toutes les issues de databricks/databricks-sql-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.