Thrift: NPE on metadata-less empty FetchResults batch with hasMoreRows=true (should skip + refetch) #1567

Summary

On the Thrift (HiveServer2) result path, databricks-jdbc throws a NullPointerException when a FetchResults response contains zero rows with hasMoreRows=true but no result-set metadata, instead of treating it as an empty intermediate batch and fetching again.

Environment

• driver: databricks-jdbc (OSS) 3.4.x, usethriftclient=1
• path: Thrift TCLIService.FetchResults with lazy fetch (EnableDirectResults=0, a RowsFetchedPerBlock batch size set)

Behavior

When the server returns a TFetchResultsResp with an empty row set, hasMoreRows=true, and getResultSetMetadata() == null (a legitimate intermediate empty batch — the next FetchResults carries the rows), the driver dereferences the null metadata and throws NPE rather than issuing the follow-up FetchResults.

Expected

The driver should tolerate a metadata-less empty batch: skip it and issue the next FetchResults until hasMoreRows=false, surfacing the full result set (this is how the C#/ADBC and other reference drivers behave).

Repro

Reproduced deterministically via the cross-driver proxy test harness (databricks-driver-test), which injects the empty-batch-with-hasMoreRows FetchResults response through mitmproxy. Covered by spec cases RESULTFETCH-009 (single empty batch) and RESULTFETCH-010 (multiple consecutive empty batches), currently committed as xfail tripwires (status: jdbc.thrift: bug) that assert the current NPE and will flip to a real pass once this is fixed.

Impact

Any Thrift query whose server-side pagination emits an empty intermediate FetchResults batch (metadata elided) fails with an NPE instead of returning rows. SEA is unaffected (server-controlled chunking, no equivalent).