Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
#927 0 comentários 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
45/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
python, sql

Direção de pesquisa

Comece pelos nomes dos testes que falham no PR de coverage e inspecione os caminhos de telemetria para Thrift e kernel/SEA, incluindo kernel/_errors.wrap_kernel_exception. Compare o comportamento pretendido com o PR de referência para a especificação de conformidade compartilhada. Considera-se concluído quando os testes TELEMETRY-001, -002, -003 e -005 passarem com telemetria completa e sanitizada do terminal e das falhas.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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

Linguagem predominante
Python
Estrelas
233
Forks
152
Merge médio
21h 5min
PRs com merge (30d)
10

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de databricks/databricks-sql-python

Todas as issues de databricks/databricks-sql-python

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.