[coverage] Conformance findings: SESSION-021

Open
  • Is something wrong?
#521 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
1-2 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
database, databases

Research direction

Start with TestStatementCreationOnClosedConnectionRejected in the coverage PR diff under tests/ and compare its expected behavior with the reference JDBC fix. Trace driver.Conn.Prepare and PrepareContext to find where closed connections should be rejected before any server call. Done means both methods reject eagerly, the connection can still run queries afterward, and the conformance assertions pass for thrift and sea.

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-go. 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-go) is fixed, then flips green as a tripwire.

Findings

  • SESSION-021 [thrift]: driver.Conn.Prepare and PrepareContext on a CLOSED connection return a statement instead of rejecting eagerly, deferring the failure to a server-side "Invalid SessionHandle" 400 at execute
    • failing test: TestStatementCreationOnClosedConnectionRejected (see the coverage PR diff under tests/)
  • SESSION-021 [sea]: driver.Conn.Prepare and PrepareContext on a CLOSED connection return a statement instead of rejecting eagerly; the kernel only fails later at execute with kernel_session_new_statement: session and out must be non-null
    • failing test: TestStatementCreationOnClosedConnectionRejected (see the coverage PR diff under tests/)
  • SESSION-021: driver.Conn.Prepare and PrepareContext on a CLOSED connection return a statement instead of rejecting eagerly, deferring the failure to execute (thrift: server-side "Invalid SessionHandle" 400; sea/kernel: kernel_session_new_statement null-session error)

Reproduce & Expected

SESSION-021 — Validates that a CLOSED connection rejects statement creation EAGERLY -- at the create/prepare/retrieve call itself, before any execution is attempted -- and that the rejected attempt leaves no stale…

Reproduce:

SELECT 1
SELECT 1
SELECT 1

Expected (per the shared spec):

  • completes without an exception
  • completes without an exception
  • completes without an exception
  • completes without an exception
  • [thrift] exactly 0 OpenSession call(s)
  • [thrift] exactly 0 ExecuteStatement call(s)
  • [sea] exactly 0 CreateSession call(s)
  • [sea] exactly 0 ExecuteStatement call(s)
  • full assertion contract:
result:
- label: baseline
  no_exception: true
  row_count: 1
- label: baseline_metadata
  no_exception: true
- label: closed_create
  error:
    contains:
    - closed
    - disposed
    - not connected
- label: closed_prepare
  error:
    contains:
    - closed
    - disposed
    - not connected
- label: after_close
  no_exception: true
  row_count: 1
- label: after_close_metadata
  no_exception: true
- label: after_close_metadata
  metadata_path_unchanged_from: baseline_metadata
protocol:
  thrift:
  - call_count:
      method: OpenSession
      expected: 0
      label: closed_create
  - call_count:
      method: ExecuteStatement
      expected: 0
      label: closed_create
  - call_min:
      method: OpenSession
      min: 1
      label: after_close
  sea:
  - call_count:
      operation: CreateSession
      expected: 0
      label: closed_create
  - call_count:
      operation: ExecuteStatement
      expected: 0
      label: closed_create
  - call_min:
      operation: CreateSession
      min: 1
      label: after_close

Context

Dominant language
Go
Stars
54
Forks
71
Avg merge
16h 3m
Merged PRs (30d)
21

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from databricks/databricks-sql-go

All issues in databricks/databricks-sql-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.