[coverage] Conformance findings: STATEMENT-025
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 64/100
Línea de trabajo
Start with TestQueryTimeoutOptionValueValidation in the coverage PR under tests, then trace the DSN timeout and dbsql.WithTimeout paths for both the Thrift and SEA/kernel backends. Compare their handling of negative values with the shared assertion contract and the reference PR. Done means invalid negative values are rejected with an error naming timeout while valid zero, positive, and maximum values retain the expected behavior.
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-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
- STATEMENT-025 [thrift]: Negative query-timeout is silently accepted: DSN
timeout=-1and dbsql.WithTimeout(-1s) both configure fine and the query runs with the invalid deadline, while non-numeric and out-of-range values ARE rejected with the option named — the value is parsed but not range-validated (PECO-3011).- failing test:
TestQueryTimeoutOptionValueValidation(see the coverage PR diff undertests/)
- failing test:
- STATEMENT-025 [sea]: Same negative-value gap on the SEA/kernel leg, and sharper: the kernel backend REFUSES any non-zero dbsql.WithTimeout up front ("not supported by the kernel backend") yet still ACCEPTS WithTimeout(-1s) and DSN timeout=-1 and runs the query — positive refused, negative waved through (PECO-3011).
- failing test:
TestQueryTimeoutOptionValueValidation(see the coverage PR diff undertests/)
- failing test:
- STATEMENT-025: Negative query-timeout values are silently accepted instead of rejected:
timeout=-1in the DSN and dbsql.WithTimeout(-1s) both configure successfully and a query then runs with the invalid deadline (behaving as "unlimited"), while non-numeric and out-of-range values ARE correctly rejected with a message naming the option — proving the value is parsed but not range-validated (PECO-3011). Affects both the Thrift and SEA/kernel backends; notably the kernel backend refuses any non-zero WithTimeout up front yet still accepts a negative one.
Reproduce & Expected
STATEMENT-025 — Validates that an INVALID value for the query-timeout option is REJECTED with an error at configuration time, on every surface that accepts the option, instead of being silently accepted and coerced…
Reproduce:
SELECT 1
SELECT 1
Expected (per the shared spec):
- completes without an exception
- result has exactly 1 row(s)
- completes without an exception
- result has exactly 1 row(s)
- completes without an exception
- completes without an exception
- completes without an exception
- full assertion contract:
result:
- label: property_non_numeric
error:
contains:
- timeout
- label: property_negative
error:
contains:
- timeout
- label: property_unrepresentable
error:
contains:
- timeout
- label: set_option_non_numeric
error:
contains:
- timeout
- label: set_option_negative
error:
contains:
- timeout
- label: set_option_unrepresentable
error:
contains:
- timeout
- label: property_zero_unlimited
no_exception: true
- label: property_zero_unlimited
row_count: 1
- label: property_max_positive
no_exception: true
- label: property_max_positive
row_count: 1
- label: set_option_valid_zero
no_exception: true
- label: set_option_valid_one
no_exception: true
- label: set_option_valid_max
no_exception: true
Context
- The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/adbc-drivers/databricks/pull/689 — 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/1692
- Lenguaje dominante
- Go
- Estrellas
- 53
- Forks
- 66
- Merge medio
- 16 h 35 min
- PR fusionados (30 d)
- 16
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de databricks/databricks-sql-go
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
databricks/databricks-sql-go#476 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
databricks/databricks-sql-go#481 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
databricks/databricks-sql-go#480 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
databricks/databricks-sql-go#475 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
databricks/databricks-sql-go#474 ·
Los mantenedores suelen responder en 1 día
Todos los issues de databricks/databricks-sql-go
Issues similares
-
bug needs triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
bug P2 reliability
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
afreidah/s3-orchestrator#1564 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
blinklabs-io/gouroboros#2577 ·
Los mantenedores suelen responder en 1 día
-
agentic-workflows
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día