Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
#927 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python, sql

Línea de trabajo

Comienza con los nombres de las pruebas que fallan en el PR de cobertura e inspecciona las rutas de telemetría de Thrift y kernel/SEA, incluido kernel/_errors.wrap_kernel_exception. Compara el comportamiento previsto con el PR de referencia para la especificación de conformidad compartida. Se considera terminado cuando las pruebas TELEMETRY-001, -002, -003 y -005 pasan con telemetría completa y saneada del terminal y de los fallos.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
233
Forks
152
Merge medio
21 h 5 min
PR fusionados (30 d)
10

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de databricks/databricks-sql-python

Todos los issues de databricks/databricks-sql-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.