[coverage] Conformance findings: LOGGING-001,LOGGING-002,LOGGING-003,LOGGING-005
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
首先检查 logger.SetLogLevel 附近的 Go 驱动日志实现，以及 client.FetchResults 附近的 fetch 路径。以 coverage PR 中列出的 conformance tests 作为行为参考，然后验证不区分大小写的级别和数字级别是否正确映射、无效级别是否在不改变日志记录的情况下发出警告，以及每页的 fetch 详情是否为 TRACE，并且只有一条 result-set 摘要为 DEBUG。
由索引模型根据 Issue 内容生成。
描述
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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
- 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 undertests/)
- failing test:
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
- 主要语言
- Go
- 星标
- 53
- 派生
- 67
- 平均合并
- 1 天 2 小时
- 30 天内合并 PR
- 8
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
databricks/databricks-sql-go 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 70/100
databricks/databricks-sql-go#494 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 64/100
databricks/databricks-sql-go#490 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 55/100
databricks/databricks-sql-go#481 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 52/100
databricks/databricks-sql-go#480 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
databricks/databricks-sql-go#475 · 1 条评论 ·
维护者通常 1 天内回复
查看 databricks/databricks-sql-go 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
维护者通常 1 天内回复
-
Add Solenta可能已有人在做 @sharmao07 今天认领。 未关闭
难度 1/5 1 小时以内 新手友好度 85/100
slavakurilyak/awesome-ai-agents#760 ·
维护者通常 1 天内回复
-
enhancement
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
-
agent-review-finding bug
难度 2/5 1-3 小时 新手友好度 68/100
jordansmall/spindrift#5281 ·
维护者通常 1 天内回复