bube opened a new issue, #9157:
URL: https://github.com/apache/paimon/issues/9157

   ### Search before asking
   
   - [x] I searched in the [issues](https://github.com/apache/paimon/issues) 
and found nothing similar.
   
   ### Paimon version
   
   master, commit e274652d7.
   
   ### Compute Engine
   
   Flink. Also reproducible via the Java API, since the code path is in 
`paimon-core`.
   
   ### Minimal reproduce step
   
   1. Configure a table with `metadata.iceberg.storage = rest-catalog`, 
pointing at any Iceberg REST catalog.
   2. Run the job with a classpath where `paimon-iceberg`'s SPI entry is 
absent, so `IcebergRESTMetadataCommitterFactory` is not discoverable. A shaded 
jar built without merging service files does this, for example Gradle's shadow 
plugin without `mergeServiceFiles()`.
   3. Write and commit.
   
   Commits succeed, Paimon data files and Iceberg metadata files are written, 
and nothing unusual is logged. No table ever appears in the catalog.
   
   ### What doesn't meet your expectations?
   
   `metadata.iceberg.storage` was set, so the sync was requested. It is 
silently disabled instead, with no way to tell from inside the job.
   
   `IcebergCommitCallback`'s constructor discards the discovery failure:
   
   ```java
   } catch (FactoryException ignore) {
       metadataCommitterFactory = null;
   }
   ```
   
   `FactoryUtil.discoverFactory` throws a `FactoryException` naming the missing 
identifier and listing what was found. It gets thrown away. 
`commitToExternalCatalog` then returns early on every commit.
   
   The failure mode is bad because everything observable still looks healthy. 
Snapshots advance and metadata files appear on disk. Only the catalog is 
broken, and you cannot see that from the job.
   
   ### Anything else?
   
   A hard failure would need care. `disabled`, `table-location` and 
`hadoop-catalog` have no committer factory by design and hit the same catch 
legitimately. Only `hive-catalog` and `rest-catalog` need one.
   
   A `WARN` seems right rather than throwing, so jobs already in this state do 
not start failing on upgrade.
   
   ### Are you willing to submit a PR?
   
   - [x] I'm willing to submit a PR!
   


-- 
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]

Reply via email to