[ES-1774740] Fix Thrift polling infinite loop on invalid operation handle

[gopalldb]

Summary

• Fix infinite poll loop on invalid handle: checkOperationStatusForErrors() now checks TStatus.statusCode for INVALID_HANDLE_STATUS during polling. Previously only operationState was checked — if the server returned INVALID_HANDLE_STATUS without setting operationState (e.g. after a driver restart), the polling loop ran indefinitely.
• Add timeout and sleep to metadata polling loop: fetchMetadataResults() previously had no timeout and no sleep between polls. It now uses a configurable MetadataOperationTimeout (default 300s) and sleeps between polls using the same interval as the SQL execution polling loop.
• New connection property: MetadataOperationTimeout (seconds, default 300, 0 = no timeout) controls the metadata polling timeout.

Context

ES-1774740: After a Databricks cluster restart, the JDBC driver entered an infinite poll loop against the invalid operation handle. The root cause was that GetOperationStatus returned INVALID_HANDLE_STATUS in TStatus.statusCode but did not set operationState, so shouldContinuePolling() kept returning true. With the default queryTimeout=0 (infinite), there was no safety net to break the loop.

The metadata polling loop (fetchMetadataResults) had a separate issue: no timeout handler and no sleep between polls, meaning it could hammer the server in a tight loop indefinitely.

SEA mode is not affected — it uses HTTP status codes (e.g. 404) for invalid statements, which propagate as uncaught RuntimeException rather than causing an infinite loop.

Test plan

• testPollingThrowsOnInvalidHandleStatus — SQL execution polling detects INVALID_HANDLE_STATUS and throws
• testMetadataPollingThrowsOnInvalidHandleStatus — metadata polling detects INVALID_HANDLE_STATUS and throws
• testMetadataPollingTimesOut — metadata polling respects timeout, cancels operation, and throws
• testMetadataPollingWithSleepBetweenPolls — verifies sleep delay between metadata polls
• All 47 tests in DatabricksThriftAccessorTest pass (43 existing + 4 new)

🤖 Generated with Claude Code

[samikshya-db]

we cannot push this until proto files are raised and merged

[gopalldb]

removed, switched to OPERATION_TIMEOUT_ERROR, will change later in separate PR to more specific error code

[vikrantpuppala]

let's remove NO_CHANGELOG=true from PR description, thanks!

[sreekanth-db]

Have we tested this manually by reproducing the issue ? Test plan in the description only mentions unit tests