Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Core: Discard changes when suppressing historical snapshots in CatalogHandlers

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#17,538 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@ebyhr đang làm issue này rồi.

Từ ngày 27/8/2026.

  • #17539 của @waterWang — đã đóng, không merge
  • #17843 của @ebyhr — đang mở

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
java
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu trong core/src/main/java/org/apache/iceberg/rest/CatalogHandlers.java tại loadTable và nhánh snapshot-loading-mode=refs của nó; so sánh việc xây dựng lại metadata với RESTSessionCatalog.loadTable. Tái hiện lỗi thông qua RESTCatalogAdapter bằng cách sử dụng một snapshot lịch sử có tệp thống kê, sau đó xác minh rằng GET .../tables/{table}?snapshots=refs thành công mà không gặp metadata-location exception.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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
Ngôn ngữ chính
Java
Star
9.3k
Fork
3.6k
Merge trung bình
2 ngày 8 giờ
Pull request đã merge (30 ngày)
143

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của apache/iceberg

Tất cả issue của apache/iceberg

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.