fix: NoTicket infinite loop when draining non-query response streams (HTTP/2 stream reset)

[Koushik-Mummina]

A customer on 3.7.1 hit this in their integration environment. When the HTTP/2 stream is reset mid-response (StreamResetException: stream was reset: CANCEL, usually due to a stale pooled connection), executeUpdate() never returns. The drain loop in InputStreamUtil.readAllBytes() catches IOException and logs it, so once the stream is dead, every read throws an exception, and there is no way out. The stuck thread also logs the same WARN line nonstop. I measured around 190k lines per second. This has been in the driver since #216, and I reproduced it on both v3.7.1 and master.

There is nothing on the client side that can stop it once it starts. The reads fail instantly instead of blocking, so socket timeouts, setQueryTimeout, and Statement.cancel() never get a chance.

What this PR changes:

1. readAllBytes now propagates the IOException instead of swallowing it
2. FireboltStatementService wraps it in a FireboltException with SQLState 08007 (transaction resolution unknown). On a mid-response reset, we genuinely cannot know if the statement was applied server-side, so the SQLState lets applications detect the in-doubt case and handle it properly.
3. The connection pool is evicted on drain failure, so the next statement gets a fresh connection instead of reusing the one that was just reset

Tests: a unit test for the loop itself. A MockWebServer test that resets the stream with CANCEL mid-body, which used to hang before the fix. A recovery test showing the follow-up statement lands on a different connection and unit coverage for SQLState and eviction.

The customer is waiting on a version to upgrade to, so please include this in a patch release once it's merged.

---

Note

Medium Risk
Changes how DML/DDL response drain failures are handled and evicts the entire OkHttp connection pool on those errors, which can affect subsequent statements and in-doubt outcomes.

Overview
Fixes a hang in non-query execution: InputStreamUtil.readAllBytes no longer swallows IOException in an infinite loop (HTTP/2 CANCEL / stream reset). Failures now propagate immediately instead of spinning and flooding WARN logs.

FireboltStatementService wraps drain failures as FireboltException with SQLState 08007 (transaction resolution unknown) and an in-doubt message, then always closes the stream. It also calls new StatementClient.evictConnectionPool() so the next statement does not reuse a reset HTTP/2 connection.

Adds unit and MockWebServer HTTP/2 tests for fail-fast behavior, SQLState, pool eviction, and recovery on a fresh connection. Includes REPRO_RESULTS.md documenting the hang and fix.

^{Reviewed by Cursor Bugbot for commit bc07cdb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b6ca6f4. Configure here.}

[cursor]

Global pool eviction blast radius

Medium Severity

evictConnectionPool() calls evictAll() on the OkHttp client from HttpClientConfig, which is a JVM-wide singleton shared by every Firebolt JDBC connection (and auth/gateway traffic). One non-query drain failure therefore drops idle pooled connections for unrelated connections, forcing reconnects process-wide instead of only retiring the stale route for that statement.

Additional Locations (1)

• src/main/java/com/firebolt/jdbc/service/FireboltStatementService.java#L122-L124

 

^{Reviewed by Cursor Bugbot for commit b6ca6f4. Configure here.}

[Koushik-Mummina]

That's accurate. The client and its pool are JVM-wide. We considered this and kept evictAll deliberately. It only closes idle connections, so nothing in flight is affected, and the cost to other connections is one extra TLS handshake on their next request. This path also only fires on a mid-body drain failure, which is rare. The other side of it is that the usual cause of the reset (LB idle timeout or GOAWAY on the shared route) likely also stalled the other idle connections in the same pool, so evicting them is more preemptive than collateral. A per-connection eviction would be nicer, but okhttp doesn't expose one publicly, and detecting connection-level causes in the service layer would mean depending on okhttp internals there.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud