yuqi1129 opened a new issue, #13949: URL: https://github.com/apache/gravitino/issues/13949
### Version branch-1.3 ### Describe what's wrong When a table load races with a concurrent metadata update on the same table, there are two problems: 1. `TableMetaService.updateTable` writes the table-version row even when the conditional `table_meta` update affected no rows. The losing (stale) update overwrites the winner's version payload, and only then reports the conflict. 2. During `loadTable`, `TableOperationDispatcher.updateColumnsIfNecessaryWhenLoad` repairs columns with a best-effort `store.update`. If that update loses the race, the conflict error makes the load drop the Gravitino metadata it already read. The column write in `updateTable` is already guarded by the update result; the version write is not. ### Error message and/or stacktrace ``` java.io.IOException: Failed to update the entity: <table identifier> ``` ### How to reproduce 1. Create a table, then change its columns in the underlying catalog, so the next `loadTable` triggers column repair. 2. Update the same table concurrently (for example, an `alterTable` from another server) so it commits after the load reads its snapshot. 3. The load's repair update hits the conflict. The table-version row now holds the stale payload, and the loaded table has no Gravitino metadata. ### Additional context Only branch-1.3 is affected in this form. Main has the OCC framework, which is too large to backport. A limited fix: skip the version write when the conditional update affects no rows, and during load-time repair keep the already-read snapshot on this specific conflict. -- 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]
