_DeleteFiles.delete_data_file() silently drops explicit file references
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 72/100
Research direction
Start in pyiceberg/table/update/snapshot.py at _DeleteFiles._compute_deletes, around line 598, and trace how delete_data_file() records explicit files. Run the reproduction from the issue, then verify that an explicitly referenced data file is deleted after commit while predicate-based deletion still works. Done means the table is empty instead of retaining [1, 2, 3].
Written by the indexing model from the issue text.
Description
Description
_DeleteFiles.delete_data_file() silently drops explicit file references because _compute_deletes resets self._deleted_data_files = set() before scanning manifests by predicate.
The delete_data_file() method is inherited from _SnapshotProducer and adds to self._deleted_data_files. However, when _DeleteFiles._compute_deletes runs (triggered by _deleted_entries()), it resets this field to an empty set and repopulates it only from files matched by the predicate evaluator. Any explicitly added files are silently lost.
While the high-level table.delete() API only uses predicates (so this isn't hit in normal usage), the low-level update_snapshot().delete() API exposes delete_data_file() as a public method. Calling it produces no error and no effect.
Reproduction
import pyarrow as pa
from pyiceberg.catalog import load_catalog
from pyiceberg.schema import Schema
from pyiceberg.types import LongType, NestedField
catalog = load_catalog("default")
catalog.create_namespace("default")
table = catalog.create_table(
"default.delete_explicit",
Schema(NestedField(1, "x", LongType(), required=False)),
)
table.append(pa.table({"x": [1, 2, 3]}))
data_file = next(iter(table.scan().plan_files())).file
# This should delete the file but silently does nothing
with table.transaction() as tx:
delete_snapshot = tx.update_snapshot().delete()
delete_snapshot.delete_data_file(data_file)
# Bug: table still has [1, 2, 3]
print(table.scan().to_arrow()["x"].to_pylist())
Expected: table is empty after commit.
Actual: table still has [1, 2, 3].
Root cause
In pyiceberg/table/update/snapshot.py, _DeleteFiles._compute_deletes (line ~598):
self._deleted_data_files = set() # <-- overwrites any explicit files added via delete_data_file()
Then it repopulates from predicate matches only. Since no predicate was set (AlwaysFalse by default), nothing matches, nothing is deleted.
Suggested fix
Before resetting, preserve explicit files and include them in the deletion scan:
# Preserve files explicitly requested for deletion
explicit_deletes = set(self._deleted_data_files)
self._deleted_data_files = set()
# ... existing predicate-based scan ...
# After the scan, also mark explicitly requested files as deleted:
for entry in manifest_entries:
if entry.data_file in explicit_deletes:
# mark as deleted
Alternatively, prevent calling delete_data_file() on _DeleteFiles entirely by raising NotImplementedError.
Related
Follow-up observation from #3818 review. The _OverwriteFiles path handles delete_data_file() correctly because it does not reset the field.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 589
- Avg merge
- 2d 4h
- Merged PRs (30d)
- 72
Contributor guide
No contributing guide indexed for this repository
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-python
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/iceberg-python#3996 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
apache/iceberg-python#3979 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/iceberg-python#3885 ·
-
[Bug] PyArrowFileIO fails to propagate s3.ssl.ca-cert to pyarrow.fs.S3FileSystem tls_ca_file_path Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
apache/iceberg-python#3866 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
apache/iceberg-python#3836 · 1 comment ·
All issues in apache/iceberg-python
Similar issues
-
Add: hunch Open
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AbdelStark/awesome-typesafe#104 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
DiamondLightSource/dodal#2211 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
openml/openml-python#1749 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sipyourdrink-ltd/bernstein#6191 ·