csurong opened a new issue, #4343: URL: https://github.com/apache/amoro/issues/4343
### What happened? AMS can synchronize external tables for formats that have catalog support but no table runtime implementation. DefaultTableService currently persists a table_runtime row before checking whether TableRuntimeFactory can create a runtime. For Paimon, the first catalog scan leaves a runtime row without an in-memory TableRuntime, and subsequent scans try to insert the same table_id again, causing duplicate primary key errors. Expected behavior: keep the synchronized table metadata, but skip table_runtime persistence when no TableRuntimeCreator is available. ### Affects Versions master ### What table formats are you seeing the problem on? _No response_ ### What engines are you seeing the problem on? _No response_ ### How to reproduce 1. Start AMS with the Paimon format profile enabled. 2. Register an external Paimon catalog that contains at least one table. 3. Trigger external catalog synchronization twice. 4. Observe that the first scan persists table_runtime even though Paimon has no runtime creator. 5. Observe a duplicate key error on the next scan. ### Relevant log output ```shell DerbySQLIntegrityConstraintViolationException: The statement was aborted because it would have caused a duplicate key value in TABLE_RUNTIME. SQL: INSERT INTO table_runtime (table_id, group_name, status_code, table_config, table_summary, bucket_id) VALUES (?, ?, ?, ?, ?, ?) ``` ### Anything else The same condition can affect any catalog-supported table format without an available TableRuntimeCreator. ### Are you willing to submit a PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's Code of Conduct -- 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]
