The manifests metadata table writes every manifest's added/existing/deleted counts into both the *_data_files_count and *_delete_files_count columns, regardless of the manifest's content type — a data manifest reports phantom delete-file counts, and a delete manifest reports phantom data-file counts.
The reference implementation gates each column by content type (ManifestsTable.java, manifestFileToRow):
manifest.content() == ManifestContent.DATA ? manifest.addedFilesCount() : 0, // added_data_files_count
manifest.content() == ManifestContent.DELETES ? manifest.addedFilesCount() : 0, // added_delete_files_count
In crates/iceberg/src/inspect/manifests.rs the six append_value sites use the same ManifestFile counts unconditionally. Easy to see with a snapshot containing one data and one deletes manifest: both rows show identical counts in all six columns.
Found while exploring #823. I have a fix with tests ready; PR incoming.
The
manifestsmetadata table writes every manifest's added/existing/deleted counts into both the*_data_files_countand*_delete_files_countcolumns, regardless of the manifest's content type — a data manifest reports phantom delete-file counts, and a delete manifest reports phantom data-file counts.The reference implementation gates each column by content type (
ManifestsTable.java,manifestFileToRow):In
crates/iceberg/src/inspect/manifests.rsthe sixappend_valuesites use the sameManifestFilecounts unconditionally. Easy to see with a snapshot containing one data and one deletes manifest: both rows show identical counts in all six columns.Found while exploring #823. I have a fix with tests ready; PR incoming.