Core: Discard changes when suppressing historical snapshots in CatalogHandlers
メンテナーはふだん 1 日以内に返信
評価
調査の方向性
core/src/main/java/org/apache/iceberg/rest/CatalogHandlers.java の loadTable と、その snapshot-loading-mode=refs ブランチから開始し、メタデータの再構築を RESTSessionCatalog.loadTable と比較します。統計ファイルを持つ過去のスナップショットを使用して RESTCatalogAdapter 経由で失敗を再現し、その後、metadata-location exception なしで GET .../tables/{table}?snapshots=refs が成功することを確認します。
索引モデルが issue の本文から書いたものです。
説明
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:
- Create a table, commit snapshot A, attach a
StatisticsFileto A (e.g.UpdateStatistics). - Commit snapshot B so A becomes historical (only reachable via parent chain, not via refs).
loadTablewithsnapshots=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
- 主要言語
- Java
- スター
- 9.3k
- フォーク
- 3.6k
- 平均マージ
- 2日 18時間
- マージ済み PR（30日）
- 122
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/iceberg のほかの issue
-
Parquet TIME_MILLIS statistics are not converted to microseconds対応中かも @chenjian2664 が 5 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
メンテナーはふだん 1 日以内に返信
-
Temporal transforms put pre-epoch timestamps at `.999999` into the previous unit対応中かも @gitedmond が 13 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
apache/iceberg#18371 · コメント 1 件 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
OpenAPI: Remove deprecated TrueExpression and FalseExpression対応中かも @zhang-arvin が 8 日前に担当しました。 オープンimprovement
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/iceberg#18351 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
Parquet: StringReader decodes every occurrence of a dictionary value into a new String対応中かも @Neuw84 が 22 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
apache/iceberg#18259 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
RCK tests fail to bind port 8181 when run alongside the kafka-connect integration stack対応中かも @Kurtiscwright が 25 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
Vakore/ZappierGames#147 ·
-
spigotmc
難易度 1/5 1時間未満 初心者へのやさしさ 92/100
Dans-Plugins/Wild-Pets#356 ·
メンテナーはふだん 1 日以内に返信
-
spigotmc
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
Dans-Plugins/Medieval-Roleplay-Engine#371 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
eddyizm/tempus#1220 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
bug javascript
難易度 1/5 1時間未満 初心者へのやさしさ 95/100
dbflute/dbflute-intro#690 ·
メンテナーはふだん 1 日以内に返信