yuqi1129 opened a new pull request, #11892:
URL: https://github.com/apache/gravitino/pull/11892
### What changes were proposed in this pull request?
`LanceTableOperations.repairTableMetadata` and `recordCheckedEmptyVersion`
run an optimistic-locked `EntityStore.update` on every `loadTable`. When two
loads repair the same table concurrently, the slower CAS matches zero rows and
surfaces as `IOException("Failed to update the entity")`, which was rethrown as
a fatal `RuntimeException("Failed to repair table")` (HTTP 500).
This wraps that update in a bounded CAS retry (`updateTableWithCasRetry`, 5
attempts): on conflict it re-reads the latest (already-repaired) entity and
re-applies the idempotent updater, returning a usable table instead of failing.
### Why are the changes needed?
Concurrent repair-on-load races (e.g. Spark parallel `LOAD` during planning
+ execution) intermittently fail table loads with HTTP 500. Seen as flaky
`LanceSparkRESTServiceIT.testSelectFromEmptyTableViaSpark`.
Fix: #11891
### Does this PR introduce _any_ user-facing change?
No.
### How was this patch tested?
Added
`TestLanceTableOperations.testLoadTableSurvivesConcurrentRepairVersionRace`: it
models a lost CAS (first `store.update` throws the conflict `IOException`, the
retry re-reads the winner's already-repaired entity) and asserts `loadTable`
returns the repaired table. It fails before the fix and passes after. The full
`TestLanceTableOperations` suite (23 tests) passes locally.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
