fix(fetch): serialize result consumption per operation to prevent concurrent-fetch row loss

[msrathore-db]

Problem

Two concurrent fetchAll() / fetchChunk() calls on a single operation could silently drop rows — the worst failure class (data loss, not an error).

The result pipeline behind every backend is a single stateful cursor. The kernel (SEA) path in particular threads shared, non-atomic prefetch state through KernelResultsProvider → ArrowResultConverter → ResultSlicer: each layer parks a pulled batch in a single look-ahead slot and mutates remainingRows / a shared recordBatchReader across await points with no guard. Two overlapping consumers interleave inside those non-atomic sections — a batch pulled off the cursor gets overwritten before it's delivered.

Reproduced on a 100k-row SELECT id FROM range(0, 100000) with two concurrent fetchAll():

Path	Before
SEA (kernel)	combined 99788 / 100000 — 212 rows lost
Thrift	passes — but only because it delivers this result set in one drainable unit, so the two loops never interleave

(For reference, the Python connector's pyo3 binding wraps the same kernel stream in a RefCell, so its second concurrent fetch fails loud with Already borrowed rather than losing data. Node's napi binding waits on a tokio::Mutex instead, so both calls proceed — which is what fed the JS overwrite window.)

Fix

Serialize all result consumption on an operation via a per-operation fetch lock in DBSQLOperation (the shared facade — so both backends behave identically by construction):

• fetchAll holds the lock across its entire drain loop (calling non-locking *Internal primitives to avoid self-deadlock).
• fetchChunk / hasMoreRows hold it per call.

Holding the lock across the whole drain (not per chunk) is what produces true Thrift parity: the first fetchAll() drains the complete result set; a concurrent second one observes an exhausted cursor and returns []. No kernel change required.

Behavior change & Thrift safety

This is a behavior change only for the (ill-defined) pattern of concurrent consumers on one operation. The everyday single-consumer path is uncontended — the lock chain is an already-resolved promise.

Verified live on both backends:

THRIFT: a=100000, b=0   combined=100000
SEA   : a=100000, b=0   combined=100000   (was 99788 before)

• overlapped fetch concurrency test: passes on both SEA and Thrift.
• Thrift fetch-path regression suite (FetchAll, FetchChunk, HasMoreRows, Iterator, ResultSlicer, LimitExact, SchemaAndDrain): 39 passing, incl. fetchAll after a partial fetchChunk(20) returning the remaining 80 rows (confirms fetchChunk→fetchAll sequencing still works through the lock).
• SEA equivalent: 38 passing.
• SEA full concurrency suite: 18 passing.

This pull request and its description were written by Isaac.

[github-actions]

Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase (git rebase -i main).

[github-actions]

Thanks for your contribution! To satisfy the DCO policy in our contributing guide every commit message must include a sign-off message. One or more of your commits is missing this message. You can reword previous commit messages with an interactive rebase (git rebase -i main).