[coverage] Conformance findings: SESSION-018

Open
#950 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
api, backend

Research direction

Start by locating the Python session path and its thrift_backend hostname handling, then compare it with the named test_server_hostname_url_scheme_parsed_case_insensitively in the coverage PR. Verify the existing lower-case behavior and reproduce the upper-case and mixed-case scheme cases. Done means explicit schemes are handled case-insensitively, while a prefix without the ':' delimiter preserves the full hostname in the error.

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-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

  • SESSION-018 [thrift]: An explicit server_hostname URL scheme is matched case-sensitively: HTTPS://<host> is not recognized/stripped, so thrift_backend re-prefixes to https://HTTPS://<host> and the driver dials hostname https instead of the workspace
    • failing test: test_server_hostname_url_scheme_parsed_case_insensitively (see the coverage PR diff under tests/)
  • SESSION-018 [sea]: The Rust kernel's config.rs::normalise_host matches the scheme with lowercase-only starts_with("https://"), so HTTPS://<host> is treated as scheme-less and re-prefixed into the unreachable https://https//<host>/api/2.0/sql/sessions
    • failing test: test_server_hostname_url_scheme_parsed_case_insensitively (see the coverage PR diff under tests/)
  • SESSION-018: An explicit server_hostname URL scheme is matched case-sensitively: HTTPS://<host> / HtTpS://<host> are not recognized or stripped, so thrift_backend re-prefixes to https://HTTPS://<host> and the driver dials hostname https instead of the workspace (RFC 3986 §3.1 requires case-insensitive schemes; the connector's own url_utils.normalize_host_with_protocol already does this but the session path bypasses it)

Reproduce & Expected

SESSION-018 — Validates how the driver parses an explicit URL scheme on its server-hostname input.

Reproduce:

SELECT 1 AS test_value
SELECT 1 AS test_value
SELECT 1 AS test_value

Expected (per the shared spec):

  • completes without an exception
  • result has exactly 1 row(s)
  • completes without an exception
  • result has exactly 1 row(s)
  • completes without an exception
  • result has exactly 1 row(s)
  • full assertion contract:
result:
- label: lower_case_scheme
  no_exception: true
  description: "APPLICABILITY GATE, not the behavior under test. If this phase fails,\
    \ the\ndriver's host input does not accept an explicit URL scheme at all \u2014\
    \ report\na capability skip citing that absent capability, NOT a driver bug, and\
    \ do\nnot run the case-folding phases.\n"
- label: lower_case_scheme
  row_count: 1
- label: upper_case_scheme
  no_exception: true
  description: 'The upper-case scheme was recognized and stripped. A driver that matched
    the

    scheme case-sensitively would carry `HTTPS://` into the hostname and fail to

    reach the workspace.

    '
- label: upper_case_scheme
  row_count: 1
- label: mixed_case_scheme
  no_exception: true
- label: mixed_case_scheme
  row_count: 1
- label: prefix_without_delimiter
  error:
    contains:
    - httpbin.invalid
  description: 'The failure names the FULL, unmodified hostname. A driver that treated
    the

    leading `http` as a scheme without requiring the `:` delimiter would report

    the mangled `bin.invalid` instead, so the full string would be absent.

    '

Context

Dominant language
Python
Stars
233
Forks
152
Avg merge
21h 5m
Merged PRs (30d)
10

Contributor guide

Open the contributing guide

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-python

All issues in databricks/databricks-sql-python

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.