Retry "already landed" check fails for an overwrite of an empty table, then deletes the landed snapshot's manifests
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
- #4023 @dancsi による — マージされずにクローズ
評価
調査の方向性
Start with Transaction.commit_transaction, especially the landed-snapshot check, and trace how Table.overwrite registers the delete and append producers. Use the reproduction in the issue to investigate the lost-response retry and cleanup behavior. Done means regression tests show the landed snapshot is recognized and its manifests remain available; the reporter says they already have a fix with tests.
索引モデルが issue の本文から書いたものです。
説明
Apache Iceberg version: 0.12.0 (also reproduced on main at ebbc0ba3e4)
Please describe the bug 🐞
After a failed attempt, Transaction.commit_transaction checks whether the attempt actually landed:
if all(
self._table.metadata.snapshot_by_id(producer._snapshot_id) is not None
for producer in self._snapshot_producers
):
A transaction can contain a producer that never creates a snapshot. Table.overwrite on an empty table (or any delete that matches nothing, followed by an append) registers a delete producer, but only the append produces an AddSnapshotUpdate. The delete producer's _snapshot_id never appears in the table, so the check is always false, even when the append landed.
pyiceberg then rebuilds and retries. On the rebuilt attempt, the delete producer's concurrency validation sees the transaction's own landed append as a concurrent conflicting write, and raises ValidationException. That goes to _clean_all_uncommitted(), which deletes the manifest list and manifests of the snapshot that landed.
Reproduction
import tempfile
import pyarrow as pa
from pyiceberg.catalog.sql import SqlCatalog
from pyiceberg.exceptions import CommitFailedException
from pyiceberg.schema import Schema
from pyiceberg.types import LongType, NestedField
warehouse = tempfile.mkdtemp()
catalog = SqlCatalog("default", uri=f"sqlite:///{warehouse}/catalog.db", warehouse=f"file://{warehouse}")
catalog.create_namespace("default")
table = catalog.create_table(
"default.t",
Schema(NestedField(1, "a", LongType(), required=False)),
properties={"commit.retry.min-wait-ms": "0"},
)
# The catalog applies the first commit, but the client sees a failure.
commit_table = catalog.commit_table
calls = 0
def commit_table_lose_first_response(*args):
global calls
calls += 1
response = commit_table(*args)
if calls == 1:
raise CommitFailedException("simulated lost response")
return response
catalog.commit_table = commit_table_lose_first_response
try:
table.overwrite(pa.table({"a": pa.array([1, 2, 3], pa.int64())}))
except Exception as e:
print(f"overwrite raised: {type(e).__name__}: {e}")
table = catalog.load_table("default.t")
snapshot = table.current_snapshot()
print("manifest list exists:", table.io.new_input(snapshot.manifest_list).exists())
table.scan().to_arrow()
Output:
Commit failed due to a concurrent update, retrying (1/4) in 0 ms
overwrite raised: ValidationException: Added data files were found matching the filter for snapshots set()!
manifest list exists: False
FileNotFoundError: [Errno 2] Failed to open local file '.../metadata/snap-...avro'
The same overwrite with a response that isn't lost succeeds, and a plain append with a lost first response is correctly detected as landed.
Suggested fix
Base the check on the snapshots the attempt actually tried to add, i.e. the AddSnapshotUpdates in self._updates, rather than on every producer. Equivalently, skip producers that didn't produce a snapshot. Ideally, a ValidationException raised during a rebuild should also never clean up a snapshot that is present in the refreshed metadata.
Related: #4021, which covers the missing check on the last attempt.
Willingness to contribute
- I would be willing to contribute a fix for this bug with guidance from the Iceberg community
I have a fix with regression tests for both this and #4021: it keys the landed check on the AddSnapshotUpdate snapshot ids that were sent, and runs it after every CommitFailedException, including on the last attempt. I'm happy to open a PR.
- 主要言語
- Python
- スター
- 1.2k
- フォーク
- 654
- 平均マージ
- 2日 11時間
- マージ済み PR(30日)
- 122
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
apache/iceberg-python のほかの issue
-
`inspect.files()` and the other file metadata tables raise `ArrowInvalid` when a snapshot has no manifests対応中かも @YuangGao が 10 日前に担当しました。 オープンkind:bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
apache/iceberg-python#4269 ·
メンテナーはふだん 1 日以内に返信
-
`inspect.entries()` raises TypeError when a data file has no column_sizes対応中かも @Rahul-cs50 が 14 日前に担当しました。 オープンkind:bug
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
apache/iceberg-python#4186 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
`older_than` reads a naive datetime as UTC and expires snapshots it should keep対応中かも @Rahul-cs50 が 13 日前に担当しました。 オープンkind:bug
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
apache/iceberg-python#4182 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
REST: Send empty first-page pageToken when rest-page-size is set対応中かも @ehddnr301 が 32 日前に担当しました。 オープンkind:bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
apache/iceberg-python#4096 ·
メンテナーはふだん 1 日以内に返信
-
PyArrowFileIO: every small S3 write is a 3-request multipart upload; expose allow_delayed_open対応中かも @David-Banquet が 29 日前に担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
apache/iceberg-python#4093 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
apache/iceberg-python の issue をすべて見る
似ている issue
-
bug
難易度 2/5 1〜3時間 初心者へのやさしさ 80/100
glossyio/traffic-monitor#312 ·
メンテナーはふだん 1 日以内に返信
-
local devenv exampleオープンdocumentation enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
es-ude/elastic-ai.creator#1046 ·
メンテナーはふだん 3 日以内に返信
-
feature request
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
confident-ai/deepteam#306 ·
メンテナーはふだん 1 日以内に返信
-
SslLibrary crashes with unhandled OSError: port/proto not found on non-standard SSL ports対応中かも @himanchalkaushale が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
OWASP/Nettacker#1884 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信