Return errors instead of panicking in fallible functions - #10755
Draft
emilk wants to merge 1 commit into
Draft
Conversation
emilk
commented
Aug 19, 2026
| /// | ||
| /// # Panics | ||
| /// | ||
| /// With the `force_validate` feature enabled, panics if `data_type`, `run_ends` |
Contributor
Author
There was a problem hiding this comment.
not sure if we should document this.
The force_validate feature has no docs in arrow-array/Cargo.toml nor in arrow-array/src/lib.rs, so I don't know what it is for.
emilk
marked this pull request as ready for review
August 19, 2026 13:34
emilk
marked this pull request as draft
August 19, 2026 13:37
These functions already return `Result`, but reported some failures by panicking. Several are reachable from untrusted input, where a panic is a denial of service rather than a bug report: * `b64_decode` panicked on invalid base64 in the input array * `read_record_batch` asserted on the variadic buffer counts declared by the IPC message, and `FileReaderBuilder::build` unwrapped footer metadata whose key or value may be absent * `Decoder::flush` (arrow-json) unwrapped a malformed tape * `FFI_ArrowSchema::metadata` unwrapped lengths supplied by the producer, and preallocated a `HashMap` for an entry count it had not checked * `ArrayData::validate_values` had `unreachable!()` arms for dictionary key and run end types, in a function whose whole job is to report bad data * `concat_elements_bytes` and `concat_elements_utf8_many` unwrapped the offset conversion, so a long enough concatenation panicked * `ColumnReader::skip_records` asserted on a page's record count * `get_row_group_column_bloom_filter` (sync and async) unwrapped the Bloom filter offsets, and subtracted them without checking * `ArrowColumnWriter::close` and `SerializedFileWriter::next_row_group` unwrapped on shared state and on overflow * the three `try_new_from_builder` dictionary builders unwrapped on a shared key buffer * the Flight SQL client unwrapped a truncated or unexpected server response * `garbage_collect_dictionary` unwrapped the new dictionary key * `data_type_from_json`, `field_from_json`, `ArrowFile::read_batch(es)` and `open_json_file` unwrapped malformed JSON Adds tests for the base64 and `validate_values` error paths. The remaining panics are documented or removed separately; this covers only the functions that could report the failure and did not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
emilk
force-pushed
the
emilk/missing-panics-doc
branch
from
August 19, 2026 14:51
3434897 to
35097d8
Compare
This was referenced Aug 19, 2026
alamb
reviewed
Aug 19, 2026
| keys_builder: new_keys | ||
| .into_builder() | ||
| .expect("underlying buffer has no references"), | ||
| keys_builder: new_keys.into_builder().map_err(|_| { |
Contributor
There was a problem hiding this comment.
Can this actually happen? I think it is fine to make it a real error, but I think it would be good to mark the error if it isn't actually expected (like "Internal Error: source keys are ....")?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Rationale for this change
While clearing
clippy::missing_panics_doc, a pattern turned up: functions thatalready return
Result, but report some failures by panicking. Several arereachable from untrusted input, so the panic is a denial of service rather than a
bug report.
Documenting those panics would normalise them, so this returns errors instead.
This is one of four PRs splitting up the work. Each one stands on its own and
touches its own set of functions, but they are meant to land in order, since the
later ones assume the earlier ones:
unwraps #10759 - remove unreachable panics#[expect(clippy::missing_panics_doc)]#10761 -#[expect]the unreachable ones, so the lint can be turned onWhat changes are included in this PR?
Only functions that could report the failure and did not. Highlights:
read_record_batchasserted on the variadic buffer counts declared by the IPCmessage, and
FileReaderBuilder::buildunwrapped footer metadata whose key orvalue may be absent
b64_decodepanicked on invalid base64 in the input arrayFFI_ArrowSchema::metadataunwrapped producer-supplied lengths, andpreallocated a
HashMapfor an entry count it had not checkedArrayData::validate_valueshadunreachable!()arms, in a function whosewhole job is to report bad data
concat_elements_bytes/concat_elements_utf8_manyunwrapped the offsetconversion, so a long enough concatenation panicked
ColumnReader::skip_recordsandget_row_group_column_bloom_filterunwrappedparquet metadata
Are these changes tested?
Covered by the existing tests, plus new tests for the
b64_decodeandArrayData::validate_valueserror paths.Are there any user-facing changes?
No API changes. Some calls that used to panic now return an
Err, which is thepoint of the PR.