rustyconover opened a new pull request, #426: URL: https://github.com/apache/arrow-dotnet/pull/426
## What's Changed `StreamExtensions.ReadFullBufferAsync`/`ReadFullBuffer` called `stream.ReadAsync`/`stream.Read` with a zero-length buffer unconditionally, whenever a message body is legitimately empty (e.g. a `RecordBatch` built from a zero-column schema, which has no buffers). Over a `MemoryStream` this is a harmless no-op, but over a real socket-backed `NetworkStream` a zero-byte read does not complete immediately — it blocks as though waiting for the peer to send more data, instead of trivially returning `0`. In a lockstep/RPC-style protocol this blocks indefinitely, since the peer is itself waiting for a response before sending anything further. Both helpers now short-circuit `buffer.Length == 0` and return `0` immediately, before ever touching the stream — matching Go's `io.ReadFull`, which documents the same special-case for a zero-length buffer. Full repro (real `pyarrow` client, real socket, `strace` evidence pinning the exact hang to this call) is in the linked issue. Added `StreamExtensionsTests.cs`: a `Stream` subclass whose `Read`/`ReadAsync` throw if ever invoked confirms the zero-length fast path never touches the underlying stream, plus two tests confirming normal non-empty reads are unaffected. `dotnet test test/Apache.Arrow.Tests` passes in full (1874 passed, 28 skipped — unrelated Python interop tests, pre-existing). Closes #425. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
