Python ManifestFile.partitions panics when partition summaries are absent
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 75/100
Research direction
Start in bindings/python/src/manifest.rs at the PyManifestFile.partitions getter, then review the optional field in crates/iceberg/src/spec/manifest_list/manifest_file.rs and the existing serialization tests. Run the focused test command from the issue after adding the regression coverage. Done means a ManifestFile with partitions: None can be accessed through Python without a panic and returns an empty list, while existing Some behavior remains unchanged.
Written by the indexing model from the issue text.
Description
Apache Iceberg Rust version
0.10.0 and current main at 4532da80f3930cdbda1cf2effe05b50165da9875.
Describe the bug
The Python PyManifestFile.partitions getter unconditionally unwraps
ManifestFile.partitions:
The core field is legitimately optional:
Existing core tests construct valid manifest-list entries with
partitions: None, serialize them as "partitions": null, and verify that
V1-to-V2 projection preserves None:
As a result, parsing such a manifest list succeeds, but accessing the Python
entry's .partitions property raises a Rust/PyO3 panic.
To reproduce
Add a focused unit test in bindings/python/src/manifest.rs that constructs
PyManifestFile around a valid ManifestFile with partitions: None, then
calls partitions().
Run:
cargo +nightly-2026-03-05 test -p pyiceberg_core_rust test_unpartitioned_manifest_partitions -- --nocapture
Observed consistently across two runs:
panicked at bindings/python/src/manifest.rs:152:14:
called `Option::unwrap()` on a `None` value
A control using partitions: Some(vec![]) passes.
Expected behavior
The list-returning Python getter should return an empty list when partition
summaries are absent, rather than panic.
Suggested fix
Use unwrap_or_default() (or equivalent optional iteration) and add a
regression test for partitions: None. Existing Some behavior should remain
unchanged.
Willingness to contribute
I would be willing to contribute a fix for this bug with guidance from the
Iceberg community.
- Dominant language
- Rust
- Stars
- 1.4k
- Forks
- 574
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 84
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/iceberg-rust
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/iceberg-rust#3234 · 1 reaction ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/iceberg-rust#3229 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/iceberg-rust#3222 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/iceberg-rust#2929 · 1 comment ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/iceberg-rust#2923 · 1 comment · 2 reactions ·
All issues in apache/iceberg-rust
Similar issues
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
bitcoindevkit/bdk-ffi#1125 ·