[coverage] Conformance findings: TELEMETRY-001,TELEMETRY-002,TELEMETRY-003,TELEMETRY-005

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

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python, sql

Research direction

Start with the failing test names in the coverage PR and inspect the telemetry paths for Thrift and kernel/SEA, including kernel/_errors.wrap_kernel_exception. Compare the intended behavior with the reference PR for the shared conformance spec. Done means the TELEMETRY-001, -002, -003, and -005 tests pass with complete, sanitized terminal and failure telemetry.

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

  • TELEMETRY-001 [thrift]: terminal statement event never populates sql_operation.operation_detail (no operation_type, no is_internal_call), so the sync-execute path is indistinguishable from the async submit path and internal-driver statements cannot be excluded from aggregates
    • failing test: test_successful_statement_execution_emits_terminal_operation_event (see the coverage PR diff under tests/)
  • TELEMETRY-001 [sea]: on the kernel/SEA backend the terminal event reports execution_result=FORMAT_UNSPECIFIED for an inline result and is_compressed from the connection's requested LZ4 setting rather than the result's declared codec, plus operation_detail is never populated (no operation_type / is_internal_call)
    • failing test: test_successful_statement_execution_emits_terminal_operation_event (see the coverage PR diff under tests/)
  • TELEMETRY-002 [thrift]: failure telemetry is exported (and correctly leaks no SQL text) but the error descriptor carries no sql_statement_id — export_failure_log reports only session_id — so it cannot be joined to the statement that failed
    • failing test: test_failed_statement_emits_sanitized_error_telemetry_without_sql_text (see the coverage PR diff under tests/)
  • TELEMETRY-002 [sea]: on the kernel/SEA backend NO error telemetry is exported for a failed statement: kernel/_errors.wrap_kernel_exception constructs PEP-249 exceptions without the host_url that exc.Error.init needs in order to reach export_failure_log, so every kernel-path failure is invisible to telemetry
    • failing test: test_failed_statement_emits_sanitized_error_telemetry_without_sql_text (see the coverage PR diff under tests/)
  • TELEMETRY-003 [thrift]: the async statement's terminal event reports no n_operation_status_calls and no operation_status_latency_millis, and is not tagged as the async issue path (operation_detail is never populated); the single-emission guarantee itself holds
    • failing test: test_async_statement_emits_one_terminal_event_with_status_poll_counters (see the coverage PR diff under tests/)
  • TELEMETRY-003 [sea]: on the kernel/SEA backend the async statement's terminal event likewise reports no n_operation_status_calls / operation_status_latency_millis and no async operation_type, so status-poll work is unmeasurable; single emission holds
    • failing test: test_async_statement_emits_one_terminal_event_with_status_poll_counters (see the coverage PR diff under tests/)
  • TELEMETRY-005 [sea]: on the kernel/SEA backend a CloudFetch/external-links result reports execution_result=FORMAT_UNSPECIFIED instead of EXTERNAL_LINKS (KernelResultSet exposes no results queue for latency_logger to classify) and is_compressed reflects the requested LZ4 setting rather than the codec the result declared
    • failing test: test_telemetry_reports_external_links_delivery_and_compression (see the coverage PR diff under tests/)
  • TELEMETRY-001: terminal statement telemetry never populates sql_operation.operation_detail (no operation_type, no is_internal_call), so the sync-execute and async-submit paths are indistinguishable and driver-internal statements cannot be excluded from aggregates; on the kernel/SEA backend execution_result is additionally always FORMAT_UNSPECIFIED and is_compressed reports the connection's requested LZ4 setting instead of the result's declared codec
  • TELEMETRY-002: on the kernel/SEA backend NO error telemetry is exported for a failed statement (kernel/_errors.wrap_kernel_exception builds exceptions without the host_url that exc.Error.init needs to reach export_failure_log), so failures are invisible to telemetry; on Thrift the descriptor is exported but carries no sql_statement_id, so it cannot be joined to the statement it describes
  • TELEMETRY-003: an async-submitted statement's terminal event reports no status-poll bookkeeping — n_operation_status_calls and operation_status_latency_millis are never populated — and is not tagged as the async issue path, so poll work performed on the application's behalf is unmeasurable (single-emission itself is correct)
  • TELEMETRY-005: on the kernel/SEA backend a CloudFetch/external-links result reports execution_result=FORMAT_UNSPECIFIED instead of EXTERNAL_LINKS (KernelResultSet exposes no results queue for latency_logger to classify) and is_compressed reflects the requested LZ4 setting rather than the codec the result declared, so result-delivery telemetry does not describe how the result actually arrived

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.