Skip to content

fix: Create file groups for partitions before applying filters #112

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
chenzl25 merged 10 commits into from
Jan 15, 2026
Merged

fix: Create file groups for partitions before applying filters #112

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
c7b2820
Update integration tests to run from MacOS laptop
nagraham Jan 5, 2026
b12a06b
Implement integ test for min_group_file_count filter on partitioned t…
nagraham Jan 5, 2026
628acf4
Fix clippy warnings
nagraham Jan 5, 2026
909fd09
Make Single and BinPack grouping strategies partition-aware
nagraham Jan 6, 2026
047b378
Add unit tests for grouping stratgies with partitioned files
nagraham Jan 7, 2026
7cb6915
Fix panic caused by the RollingIcebergWriter not using correct partit…
nagraham Jan 8, 2026
eafb977
Fix flakey integration test
nagraham Jan 8, 2026
263ebca
Change partition_spec parameter to a boolean
nagraham Jan 14, 2026
d8e0155
Refactor partition handling in the file selection strategy
nagraham Jan 14, 2026
19166aa
Remove is_partitioned parameter
nagraham Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 1 addition & 8 deletions core/src/executor/iceberg_writer/rolling_iceberg_writer.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -433,7 +433,6 @@ pub struct RollingIcebergWriterBuilder<B> {
max_concurrent_closes: Option<usize>,
enable_dynamic_size_estimation: Option<bool>,
size_estimation_smoothing_factor: Option<f64>,
partition_key: Option<PartitionKey>,
}

impl<B> RollingIcebergWriterBuilder<B> {
Expand All @@ -444,7 +443,6 @@ impl<B> RollingIcebergWriterBuilder<B> {
max_concurrent_closes: None,
enable_dynamic_size_estimation: None,
size_estimation_smoothing_factor: None,
partition_key: None,
}
}

Expand All @@ -470,11 +468,6 @@ impl<B> RollingIcebergWriterBuilder<B> {
self.size_estimation_smoothing_factor = Some(factor);
self
}

pub fn with_partition_key(mut self, partition_key: PartitionKey) -> Self {
self.partition_key = Some(partition_key);
self
}
}

#[async_trait::async_trait]
Expand Down Expand Up @@ -503,7 +496,7 @@ where
max_concurrent_closes: self
.max_concurrent_closes
.unwrap_or(DEFAULT_MAX_CONCURRENT_CLOSES),
partition_key: self.partition_key,
Copy link
Collaborator Author

@nagraham nagraham Jan 8, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discovered this triggers a panic deeper in iceberg-rust. The root cause is self.partition_key is set to None. However, the RecordBatchPartitionSplitter will provide a partition_key when build() is invoked. We should use that partition_key instead. By using None, we have invalid partition data. I think the first instance works because the initial writer has the correct partition_key.

This triggered a panic in construct_partition_summaries due to the iterators not having the same length. Long term, iceberg-rust should probably return a better error rather than panic. But perhaps panicking is better than writing corrupted data.

Truncated stack trace:

itertools: .zip_eq() reached end of one iterator before the other
iceberg::spec::manifest::writer::ManifestWriter::construct_partition_summaries
iceberg::spec::manifest::writer::ManifestWriter::write_manifest_file
iceberg::transaction::snapshot::SnapshotProducer::write_added_manifest
iceberg::transaction::rewrite_files::RewriteFilesAction::commit

I wrote a 2nd integration test and verified that it triggers a panic without this modification. It also demonstrates the conditions which trigger the error:

  1. The table must be partitioned
  2. At least one partition must have a group of input files which is larger than the target_size, and thus triggers a "roll over" to a new output file

Copy link
Collaborator

@chenzl25 chenzl25 Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should refactor the RollingIcebergWriterBuilder as well, since the self.partition_key is useless.

Copy link
Collaborator Author

@nagraham nagraham Jan 14, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. Done!

partition_key,
})
}
}
Expand Down
1 change: 0 additions & 1 deletion core/src/file_selection/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,6 @@ impl FileSelector {
})
.try_collect()
.await?;

Ok(data_files)
}

Expand Down
Loading