JingsongLi commented on PR #10078: URL: https://github.com/apache/paimon/pull/10078#issuecomment-5953398958
Revalidated on `f7114bbcd0cccc496fa299b6f4f709371f2fc9aa`: the [previous P1 ownership finding](https://github.com/apache/paimon/pull/10078#discussion_r4068901232) remains unresolved. I reproduced this through real `HiveCatalog.createTable` calls against an embedded HMS. After the losing external create had written its schema, another catalog registered the same identifier at a different location and committed a row. The loser's HMS registration then raised `AlreadyExistsException`. `cleanupOnCreateTableFailure` dropped the winner's HMS entry; with a managed winner, `deleteData=true` also removed its actual Parquet file. Removing only the new cleanup invocation preserved both the external and managed winners and their data. Please remove this cleanup from the location fix, or establish ownership of the registered table before deleting it, including excluding `AlreadyExistsException`. The current cleanup test does not establish ownership. A competing successful create should be covered by a regression test. The schemeless-location fix has useful end-to-end value. All 58 `HiveCatalogTest` tests passed locally on JDK 8 with normal Maven checks, including the corrected temporary-directory fixture. Seven URI-resolution cases also passed (HDFS authority/nameservice, S3A, local default, explicit schemes, and an explicit authority). These URI checks do not replace an actual HDFS integration run. The current CI run still reports failed Core JDK 8/11 and Flink 1 Connectors/CDC jobs; their logs could not be retrieved locally, so I have not independently classified those failures. -- 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]
