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

Core: Discard changes when suppressing historical snapshots in CatalogHandlers

Aperta Adatta ai principianti
  • Qualcosa non va?
#17,538 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ebyhr ci sta già lavorando.

Dal 27/8/2026.

  • #17539 di @waterWang — chiusa senza merge
  • #17843 di @ebyhr — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
java
Ambito
api, backend

Direzione di ricerca

Iniziare in core/src/main/java/org/apache/iceberg/rest/CatalogHandlers.java, in loadTable e nel relativo ramo snapshot-loading-mode=refs; confrontare la ricostruzione dei metadati con RESTSessionCatalog.loadTable. Riprodurre il fallimento tramite RESTCatalogAdapter usando uno snapshot storico con un file di statistiche, quindi verificare che GET .../tables/{table}?snapshots=refs abbia esito positivo senza la metadata-location exception.

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

Descrizione

bug
Apache Iceberg version

1.11.0 (latest release)

Query engine

None

Please describe the bug 🐞

Behavior

In snapshot-loading-mode=refs, CatalogHandlers.loadTable fails with IllegalArgumentException: Cannot set metadata location with changes to table metadata: 1 changes when serving GET .../tables/{table}?snapshots=refs for a table that has a statistics file (or partition statistics file) attached to a historical (unreferenced) snapshot.

Cause

The REFS branch builds the response metadata like this (CatalogHandlers.java#L526-L531):

metadata =
    TableMetadata.buildFrom(loadedMetadata)
        .withMetadataLocation(loadedMetadata.metadataFileLocation())
        .suppressHistoricalSnapshots()
        .build();

suppressHistoricalSnapshots() does not record RemoveSnapshots changes, but it removes the suppressed snapshots' statistics via removeStatistics(...) / removePartitionStatistics(...), which do record MetadataUpdate.RemoveStatistics / RemovePartitionStatistics changes (TableMetadata.java, rewriteSnapshotsInternal). build() then rejects the combination of pending changes and a set metadata location.

The client-side equivalent in RESTSessionCatalog.loadTable already prevents this with by calling .discardChanges() when rebuilding metadata; CatalogHandlers performs the change-recording suppression without that measure.

To Reproduce

E.g. via RESTCatalogAdapter with snapshot-loading-mode=refs on the client:

  1. Create a table, commit snapshot A, attach a StatisticsFile to A (e.g. UpdateStatistics).
  2. Commit snapshot B so A becomes historical (only reachable via parent chain, not via refs).
  3. loadTable with snapshots=refs → 500 / IllegalArgumentException: Cannot set metadata location with changes to table metadata: 1 changes.

Encountered in practice testing Trino's REST catalog against the in-memory test server with snapshot-loading-mode=refs: Trino writes statistics on INSERT by default, so the first loadTable after a stats-bearing snapshot becomes historical reliably fails.

Suggested Fix

Add .discardChanges() to the builder chain in CatalogHandlers.loadTable (matching the client-side wrapper), e.g.

TableMetadata.buildFrom(loadedMetadata)
    .withMetadataLocation(loadedMetadata.metadataFileLocation())
    .suppressHistoricalSnapshots()
    .discardChanges()
    .build();

This would be the minimal fix, keeping the general behavior as is. Alternatively, the suppress-parameter that already prevents MetadataUpdate.RemoveSnapshots changes from being created here could be incorporated into removeStatistics() and removePartitionStatistics() to prevent change creation there at the root.

AI assistance

Found this while working on a trino patch. This root-cause analysis was AI-assisted. I'm quite confident this is an actual bug and checked this in detail before opening the issue. I'll link to the related PR at trino shortly, whose test triggers this behavior.

Willingness to contribute
  • I can contribute a fix for this bug independently
  • I would be willing to contribute a fix for this bug with guidance from the Iceberg community
  • I cannot contribute a fix for this bug at this time
Lingua principale
Java
Stelle
9.3k
Fork
3.6k
Merge medio
2g 20h
PR unite (30g)
142

Preparare l'ambiente

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/iceberg

Tutte le issue di apache/iceberg

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.