Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#4,352 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Anurag15v ya está trabajando en esto.

Desde el 3/10/2026.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
java
Área
data-engineering, databases

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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!
Lenguaje dominante
Java
Estrellas
2.2k
Forks
646
Merge medio
2 d 28 min
PR fusionados (30 d)
128

Preparar el entorno

  • Sin Dockerfile ni archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/fluss

Todos los issues de apache/fluss

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.