salimTutuncu commented on issue #889: URL: https://github.com/apache/incubator-xtable/issues/889#issuecomment-5541331527
Adding a measured data point that strengthens the "real exit codes" part of this request, from an evaluation of the 0.4.0 spark-runtime. A target-side sync failure can currently complete with **exit code 0**. We reproduced it by making the Iceberg target's `metadata/` directory unwritable: the sync failed, the log contained the permission error and `Sync failed for the following formats ICEBERG`, and then the CLI logged `Completed XTable sync for ...` and exited 0. A forced scan showed the source at 200 rows while the target remained at 100. Mechanism, at the release commit: `TableFormatSync` converts target exceptions into ERROR `SyncResult`s (https://github.com/apache/incubator-xtable/blob/e8f22867a6cb297f58b248150220fce71188d16a/xtable-api/src/main/java/org/apache/xtable/spi/sync/TableFormatSync.java#L64-L139), and `XTableSparkSync.main` counts only *thrown* exceptions, never inspecting the returned status map (https://github.com/apache/incubator-xtable/blob/e8f22867a6cb297f58b248150220fce71188d16a/xtable-spark-runtime/src/main/java/org/apache/xtable/spark/XTableSparkSync.java#L246-L277). For contrast, the binary-linkage failures we tested (`NoSuchMethodError` from incompatible Hudi/Kernel versions) did exit nonzero, consistent with `java.lang.Error` escaping the `catch (Exception)` handler. Until this lands, schedulers cannot rely on exit codes alone for target failures; they must parse logs or validate the target. Happy to share the full reproduction script if useful. -- 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]
