[WIP][AMORO-4292][AMS] Guard IcebergTableMaintainer orphan cleanup against shared table locations - #4293
Open
terrytlu wants to merge 2 commits into
Open
Conversation
github-actions
Bot
added
type:docs
terrytlu
changed the title
…ed table locations IcebergTableMaintainer.cleanOrphanFiles() lists and deletes files under a table's location. When two Iceberg tables share the same location (for example, one table is created from another's metadata directory, or a snapshot is restored into the same path), the cleanup of table A can delete files that actually belong to table B, silently corrupting B. This is the same root cause reported for Iceberg in apache/iceberg#17213. This change adds a pre-check, IcebergTableUtil.hasOtherTableInLocation(Table), that lists the table's metadata directory via its own (storage-agnostic) FileIO and compares the table-uuid of every other metadata.json with the current table's uuid. If another table is detected in the same location, cleanOrphanFiles() now skips cleanup by default (fail-closed) instead of risking another table's files. A new table property, clean-orphan-file.ignore-location-conflict (default false), lets users opt out of the check when they are certain the location is not shared. Fixes apache#4292 Signed-off-by: terrytlu <terrytlu@tencent.com>
terrytlu
force-pushed
the
AMORO-4292-orphan-clean-location-conflict
branch
2 times, most recently
from
August 7, 2026 10:42
947fb94 to
bd9a4b6
Compare
terrytlu
changed the title
…ed table locations, add metrics monitoring orphan file cleaning status Introduce last-value gauges to track orphan-file-cleaning outcomes: - table_orphan_file_cleaning_last_status (0=SUCCESS, 1=CONFLICT_DETECTED, 2=CHECK_UNAVAILABLE, 3=EXECUTION_FAILED) - table_orphan_file_cleaning_last_failure_timestamp_ms MaintainerMetrics gains CleanFailureReason and recordSuccess/recordFailure. IcebergTableMaintainer wraps cleanup in try/catch and records success/failure, with location-conflict check returning CONFLICT_DETECTED/CHECK_FAILED.
terrytlu
force-pushed
the
AMORO-4292-orphan-clean-location-conflict
branch
from
August 14, 2026 03:06
bd9a4b6 to
9c2d96d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #4292
What changes were proposed in this pull request?
IcebergTableMaintainer.cleanOrphanFiles() lists and deletes files under a table's location. When two Iceberg tables share the same location (e.g. one table is created from another's metadata directory), the cleanup of table A can delete files that actually belong to table B, silently corrupting B.
This PR adds a pre-check,
IcebergTableUtil.hasOtherTableInLocation(Table):FileIO(requiresSupportsPrefixOperations; otherwise aValidationExceptionis thrown so the caller can decide);table-uuidof every othermetadata.jsonwith the current table's uuid;If another table is detected in the same location,
cleanOrphanFiles()now skips cleanup by default (fail-closed) instead of risking another table's files. A new table propertyclean-orphan-file.ignore-location-conflict(defaultfalse) lets users opt out of the check when they are certain the location is not shared.Why are the changes needed?
Without the guard, a single misconfigured / duplicated table location leads to silent cross-table data loss during scheduled orphan-file cleanup.
How was this patch tested?
TestIcebergOrphanFileLocationConflict(5 cases × 2 Iceberg parameterizations = 10 tests): no conflict, conflict via corrupt metadata,ValidationExceptionwhen FileIO lacks prefix support, default skip-on-conflict, and ignore-conflict-when-property-enabled proceeds with cleanup.mvn test -pl amoro-ams -Dtest=TestIcebergOrphanFileLocationConflict→ Tests run: 10, Failures: 0, Errors: 0.spotless:checkpasses.Documentation
This PR introduces a new table property
clean-orphan-file.ignore-location-conflict(defaultfalse), which allows users to bypass the shared-location check when they are certain the table location is not shared. The property is documented indocs/user-guides/configurations.md(Self-optimizing / table maintenance configurations section).