ranflarion opened a new issue, #10563: URL: https://github.com/apache/arrow-rs/issues/10563
**Describe the bug** `PushBuffers::push_range` asserts that the pushed buffer's length equals the range's length ([parquet/src/util/push_buffers.rs](https://github.com/apache/arrow-rs/blob/main/parquet/src/util/push_buffers.rs), "Range length must match buffer length"), and `push_ranges` asserts `ranges.len() == buffers.len()`. Both decoder entry points that feed it, `ParquetMetaDataPushDecoder::push_range`/`push_ranges` and `ParquetPushDecoder::push_ranges`, return `Result`, but a length mismatch bypasses the error channel and panics instead. The practical way to hit this is a short read: an `AsyncFileReader::get_byte_ranges` implementation backed by a store that can deliver fewer bytes than the requested range (truncated body, buggy caching layer, fault injection) panics the reader thread instead of failing the read. The caller gets no `Err` to classify or retry, and on a multi-threaded runtime the panic can take down sibling work on the worker. The equivalent fault in the json and avro readers surfaces as a decode error. **To Reproduce** ```rust let mut decoder = ParquetMetaDataPushDecoder::try_new(100)?; // the range promises 10 bytes, the buffer has 4: // panics "Range length must match buffer length" although push_range returns Result decoder.push_range(10..20, Bytes::from_static(b"abcd"))?; ``` We originally hit it through the async reader in fault-injection testing: a store wrapper that truncates one ranged read mid-file panics the stream at `push_buffers.rs` instead of yielding an error the read layer can absorb. **Expected behavior** The mismatch is reported through the existing `Result` channel, e.g. `Parquet error: Buffer length (4) does not match length (10) of range 10..20`, so callers can surface or retry the failed read. **Additional context** Happy to submit a PR. The change makes `PushBuffers::push_range`/`push_ranges` return `Result<(), ParquetError>` and propagates through the crate-internal chain (`RowGroupReaderBuilder::push_data`, `RemainingRowGroups::push_data`, `ParquetDecoderState::push_data`); the public decoder entry points already return `Result`, so there is no stable API change (`PushBuffers` itself is only exported under the `experimental` feature). Related to the earlier robustness reports for the avro reader (#10493, #10494). -- 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]
