Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

_DeleteFiles.delete_data_file() silently drops explicit file references

Ouverte
#3,857 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@qzyu999 y travaille déjà.

Depuis le 26/8/2026.

  • #3858 par @qzyu999 — ouverte

Évaluation

Difficulté
3/5
Temps estimé
1-2 jours
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
python
Domaine
databases

Piste de recherche

Commencez dans pyiceberg/table/update/snapshot.py, à _DeleteFiles._compute_deletes, vers la ligne 598, et suivez la façon dont delete_data_file() enregistre les fichiers explicitement indiqués. Exécutez la reproduction de l’issue, puis vérifiez qu’un fichier de données référencé explicitement est supprimé après le commit, tandis que la suppression basée sur un prédicat continue de fonctionner. C’est terminé lorsque la table est vide au lieu de conserver [1, 2, 3].

Rédigé par le modèle d'indexation à partir du texte de l'issue.

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.

Langage dominant
Python
Étoiles
1.2k
Forks
618
Merge moyen
1 j 10 h
PR mergées (30 j)
71

Préparer son environnement

  • Aucun Dockerfile ni fichier Docker Compose
  • Propose un modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de apache/iceberg-python

Toutes les issues de apache/iceberg-python

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.