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
- CLOUDFETCH-017 [thrift]: A CloudFetch chunk downloaded with HTTP 200 but a corrupt compressed body fails in the decompressor, yet the cause is re-wrapped into an unrelated row-indexing/Arrow message ("row number 0 is not contained in any arrow batch ... unexpected EOF"), so the caller cannot identify decompression as the cause (PECOBLR-3537)
- failing test:
TestCloudFetchDecompressionFailureSurfacesAsDecompressionError (see the coverage PR diff under tests/)
Reproduce & Expected
CLOUDFETCH-017 — When a CloudFetch chunk downloads SUCCESSFULLY (HTTP 200) but its body is not a valid compressed frame, the driver fails inside its decompressor rather than on the HTTP status. The error the caller receives MUST identify DECOMPRESSION as the cause. This is the one CloudFetch failure mode that is not an HTTP failure: every cloudfetch_ scenario fails the request, so the driver never reaches its decompression step. Because a corrupt payload is a permanent condition (unlike an expired link), a fresh presigned URL does not help -- the driver retries the same URL, exhausts its budget, and must then surface a decompression error. Regression guard: before the fix the raw decompressor error was propagated untagged and re-wrapped downstream into an unrelated row-indexing message ("row number not contained"), so the true cause was invisible to the caller and the failure was misclassified in telemetry as a generic error. The contract is that the cause survives to the caller as a decompression error, and that the process/connection stays usable afterwards.
Reproduce:
- A result large enough to be delivered via CloudFetch external links.
Expected (per the shared spec):
result:
- error:
contains:
- decompress
- decompression
- lz4
- connection_usable_after_error: true
protocol:
thrift:
- cloud_downloads_min: 1
sea:
- cloud_downloads_min: 1Context
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
TestCloudFetchDecompressionFailureSurfacesAsDecompressionError(see the coverage PR diff undertests/)Reproduce & Expected
CLOUDFETCH-017 — When a CloudFetch chunk downloads SUCCESSFULLY (HTTP 200) but its body is not a valid compressed frame, the driver fails inside its decompressor rather than on the HTTP status. The error the caller receives MUST identify DECOMPRESSION as the cause. This is the one CloudFetch failure mode that is not an HTTP failure: every cloudfetch_ scenario fails the request, so the driver never reaches its decompression step. Because a corrupt payload is a permanent condition (unlike an expired link), a fresh presigned URL does not help -- the driver retries the same URL, exhausts its budget, and must then surface a decompression error. Regression guard: before the fix the raw decompressor error was propagated untagged and re-wrapped downstream into an unrelated row-indexing message ("row number not contained"), so the true cause was invisible to the caller and the failure was misclassified in telemetry as a generic error. The contract is that the cause survives to the caller as a decompression error, and that the process/connection stays usable afterwards.
Reproduce:
Expected (per the shared spec):
Context