GeezerVison

DBSQLOperation.close() rethrew any failure of the close request. A teardown CloseOperation that failed after the results were fully read (e.g. a 404) therefore escaped close(), and the rest of the teardown was skipped: the operation stayed open locally (reads were not blocked), stayed registered on its session, and never emitted statement-complete telemetry. The same happened to autoClose iterators and streams at the end of the data, and on the kernel backend whenever its CloseStatement fails.

The fix is in the DBSQLOperation facade, so it covers both backends. Once the backend has reported the statement finished, a failed close is logged at warn, emitted as error telemetry (as before), and reported in the returned Status's info. The operation is then closed locally as usual. The server-side result is also freed when the session closes. Before the statement has finished, a close failure still throws and the operation stays open so the close can be retried, because there the close is what stops a running statement.

Verification: new unit tests cover both backends with a mocked failing close (HTTP 404 and an error status): drained results, finished(), an autoClose iterator, the session-close cascade, and the still-throwing case before the statement finishes. All of them failed on main. npm test (1535 passing), lint, type-check, and build pass. A live script against a warehouse, run on Thrift and useKernel: true, checks three cases: a normal close after draining 10k rows; a close failure injected after draining (close() resolves, a warning is logged, reads are refused, and SELECT 1 on the same session still works); and a close failure on a running query (still throws, then the retry succeeds). The injected-failure case fails on origin/main on both backends.

Performance: the only addition to the default path is one flag store per wait. An in-memory micro-benchmark (200k chunks, 15 alternating fresh-process runs) gave a median of 202.3 ms on main and 204.7 ms on this branch, within the 0.9% A/A noise. Live execute+drain+close of range(100000), alternating builds: Thrift 594.1 vs 600.3 ms (8 runs each), kernel 300.0 vs 304.6 ms (4 runs each), with overlapping ranges.

Fixes #480

This pull request and its description were written by Isaac.