Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

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

未關閉
#927 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

還沒有人認領這個 Issue。

評估

難度
4/5
預估耗時
3-5 天
新手友好度
45/100
Issue 類型
缺陷
描述清晰度
基本清楚
活躍度
活躍
技術堆疊
python, sql

研究方向

從 coverage PR 中失敗的測試名稱開始,檢查 Thrift 和 kernel/SEA 的遙測路徑,包括 kernel/_errors.wrap_kernel_exception。將預期行為與 shared conformance spec 的 reference PR 進行比較。當 TELEMETRY-001、-002、-003 和 -005 測試在終端與失敗遙測完整且經過清理的情況下通過時,即視為完成。

由索引模型根據 Issue 內容生成。

描述

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

主要語言
Python
星號
233
分支
152
平均合併
1 天 23 小時
30 天內合併 PR
11

貢獻指南

開啟貢獻指南

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

databricks/databricks-sql-python 的其他 Issue

查看 databricks/databricks-sql-python 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。