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

Bắt đầu bằng cách kiểm tra phần triển khai logging của Go driver xung quanh logger.SetLogLevel và đường dẫn fetch xung quanh client.FetchResults. Sử dụng các bài kiểm tra tính tuân thủ được nêu tên trong coverage PR làm tham chiếu về hành vi, sau đó xác minh rằng các level không phân biệt chữ hoa chữ thường và các level dạng số được ánh xạ chính xác, các level không hợp lệ phát cảnh báo mà không thay đổi logging, và chi tiết fetch của từng trang ở mức TRACE, với đúng một bản tóm tắt result set ở mức DEBUG.

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-sql-go. 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-go) is fixed, then flips green as a tripwire.

Findings

• LOGGING-001 [thrift]: logger.SetLogLevel rejects its own level names in upper/mixed case (TRACE/Info/WARN/Debug) because the value is passed verbatim to zerolog.ParseLevel, and the rejection also resets the logger to NoLevel
  • failing test: TestNamedLogLevelValuesAcceptedCaseInsensitively (see the coverage PR diff under tests/)
• LOGGING-002 [thrift]: a numeric LogLevel is mapped on zerolog's inverted scale, so a DSN copied from JDBC gets the opposite verbosity: "6" (TRACE) silences the log and "0" (OFF, the JDBC sample default) enables full debug logging
  • failing test: TestNumericLogLevelFromReferenceDriverAcceptedAndMapped (see the coverage PR diff under tests/)
• LOGGING-003 [thrift]: an unrecognised log level emits no WARN naming the value in the configured destination and still applies zerolog's NoLevel fallback, silencing the process-wide logger and downgrading an already-more-verbose level instead of being ignored
  • failing test: TestUnrecognisedLogLevelIgnoredWithWarningNotConnectFailure (see the coverage PR diff under tests/)
• LOGGING-005 [thrift]: per-page fetch records (client.FetchResults / "fetching result page for row N") are emitted at DEBUG rather than TRACE, so DEBUG log volume grows with the fetch count (16 records for a 5-row read with a 1-row page cap)
  • failing test: TestPerFetchLogDetailAtTraceWithOneSummaryPerResultSetAtDebug (see the coverage PR diff under tests/)

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/252 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-sql-go; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1267