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

Aperta
  • Qualcosa non va?
#927 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python, sql
Ambito
backend, observability

Direzione di ricerca

Inizia dai nomi dei test che falliscono nella PR di coverage e ispeziona i percorsi di telemetria per Thrift e kernel/SEA, incluso kernel/_errors.wrap_kernel_exception. Confronta il comportamento previsto con la PR di riferimento per la specifica di conformità condivisa. Il lavoro è completato quando i test TELEMETRY-001, -002, -003 e -005 passano con una telemetria completa e sanificata del terminale e degli errori.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
236
Fork
162
Merge medio
13h 13m
PR unite (30g)
23

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di databricks/databricks-sql-python

Tutte le issue di databricks/databricks-sql-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.