Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Iceberg compaction always fails for primary-key tables — RewriteFiles committed after RowDelta

Aperta
  • Qualcosa non va?
#4,352 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Anurag15v ci sta già lavorando.

Dal 3/10/2026.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
data-engineering, databases

Direzione di ricerca

Start in IcebergLakeCommitter.commit() around lines 132 and 139, then read IcebergRewriteTest to understand the existing append-only coverage. Add coverage for a primary-key table with equality deletes and verify RewriteFiles is committed before RowDelta. Done means rewrite commits succeed, replace operations appear in snapshot history, and compacted file counts decrease.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Search before asking
  • I searched in the issues and found nothing similar.
Fluss version

0.9.1-incubating

Please describe the bug 🐞

IcebergLakeCommitter.commit() commits the RowDelta (new data + equality deletes) before the RewriteFiles (compaction). For PK tables using merge-on-read, every RowDelta adds equality delete files targeting existing data files in the same partitions. When commitRewrite() runs immediately after, validateFromSnapshot() detects those new deletes and rejects the commit.

Log evidence:

ERROR org.apache.fluss.lake.iceberg.tiering.IcebergLakeCommitter - Failed to commit rewrite files to iceberg, delete rewrite added files [...]
org.apache.iceberg.exceptions.ValidationException: Cannot commit, found new delete for replaced data file: GenericDataFile{content=data, ...}
    at org.apache.iceberg.exceptions.ValidationException.check(ValidationException.java:49)

This happens on every commit cycle for PK tables. The snapshot history confirms compaction never commits — every operation is overwrite (RowDelta), never replace (RewriteFiles):

operation    total-data-files
overwrite    312
overwrite    310
overwrite    308
overwrite    306

The file count grows monotonically (one file per bucket per commit), with no compaction.

Root cause: Commit ordering in IcebergLakeCommitter.commit() (line 132 vs 139). The RowDelta commits first, adding equality deletes that target the files the rewrite wants to replace.

// Current: RowDelta first, RewriteFiles second
long snapshotId = commit(snapshotUpdate, snapshotProperties);  // line 132 — RowDelta adds deletes

List<RewriteDataFileResult> rewriteDataFileResults =
        committable.rewriteDataFileResults();
if (!rewriteDataFileResults.isEmpty()) {
    Long rewriteCommitSnapshotId =
            commitRewrite(rewriteDataFileResults, snapshotProperties);  // line 139 — always fails
}

Append-only tables are unaffected because AppendFiles adds no delete files.

Test coverage gap: The existing IcebergRewriteTest only covers append-only tables (no identifier fields in the schema). PK tables with equality deletes are untested.

Also affects main (as of dd2d30a).

Solution

Swap the commit order — RewriteFiles first, RowDelta second. The rewrite validates from the snapshot it was planned against; committing it before the RowDelta means no new deletes exist yet, so validation passes. The RowDelta's equality deletes then correctly target the compacted files (which have a lower sequence number).

After applying the fix, replace operations appear and the file count drops immediately:

operation    total-data-files
overwrite    4
replace      2
overwrite    6
Are you willing to submit a PR?
  • I'm willing to submit a PR!
Lingua principale
Java
Stelle
2.2k
Fork
656
Merge medio
2g 2h
PR unite (30g)
120

Preparare l'ambiente

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/fluss

Tutte le issue di apache/fluss

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.