fix: handle all exceptions to support Kotlin by dvob · Pull Request #2965 · operator-framework/java-operator-sdk

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

dvob · 2025-09-25T06:57:02Z

When using JOSDK with Kotlin I ran into the problem that the retry did not work when the create method of a DependentResource throws an Exception not inherited from RuntimeException.

The change switches the handling from RuntimeException to Exception so that it works with Kotlin where you can throw Exceptions from methods which don't declare that they throw.

I changed this in the NodeExecutor to address the problem I specifically ran into. Then I also grepped for other places where RuntimeException is catched and then changed it in PollingEventSource as well.

Maybe there are other places (e.g. OperatorException) which should be changed.

csviri · 2025-09-25T07:09:21Z

Hi @dvob I'm not against this, we probably don't want to change OperatorException. So you were able to test this PR, with properly with kotlin?

csviri

I think that we should at least comment on those places that Exception is required because of kotlin

csviri · 2025-09-25T07:13:23Z

also created a followup issue: #2967

dvob · 2025-09-25T07:22:17Z

Theoretically this is for all JVM-languages which do not have the concept of checked vs. unchecked exceptions and not just for Kotlin. But not sure if in practice any other language is used.

Yes, I tested this with Kotlin and it fixed the problem (reconcile of DependentResource which throws Exception now causes a retry)

I will go ahead and add the comments at the places where we catch Exception, ok?
Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

csviri · 2025-09-25T07:24:53Z

I will go ahead and add the comments at the places where we catch Exception, ok?

Yes, pls.

Do you want me to put this into the same commit or add a second commit and then you can squash it on merging?

Does not matter; we squash commits.

Thank you!

dvob · 2025-09-25T07:35:28Z

I added the comments and also fixed the typos in the commit message

Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

xstefank

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

csviri · 2025-09-25T10:25:14Z

I'm OK with this but shouldn't this be considered a breaking change? If someone indeed is now throwing RuntimeException it will stop working?

I don't see how it would stop working, could you pls elaborate?

xstefank · 2025-09-25T12:12:50Z

scratch that, forgot which exception extends which exception

…ator E2E test (#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before #2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closes#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

…ator E2E test (operator-framework#3513) Adds a Maven-compiled Kotlin test source set to operator-framework-core and a smoke test verifying that a checked (non-RuntimeException) Exception thrown from a Kotlin DependentResource is properly caught and reported by the workflow executor, so that retries are triggered as expected. Kotlin does not have checked exceptions, so Kotlin code can throw a checked Exception from an overridden method without declaring it, even though the Java DependentResource#reconcile signature does not declare `throws Exception`. Before operator-framework#2965 this exception would not have been caught by NodeExecutor, since it only handled RuntimeException, silently swallowing the error and preventing retries. Closesoperator-framework#2967 * Potential fix for pull request finding Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * fix: close class brace in Kotlin test; add Kotlin sample operator E2E Fixes a missing closing brace left in KotlinCheckedExceptionDependentResourceTest.kt. Adds a new sample-operators/kotlin-operator module: a minimalist Kotlin operator (ConfigMapCopyReconciler) that copies a value from a custom resource's spec into a ConfigMap, with a dual-mode (local/remote) E2E test mirroring the other samples. This verifies deserialization via the fabric8 client and the full reconciliation runtime when both the CR and reconciler are implemented in Kotlin, addressing the maintainer's request for broader coverage than the existing unit-level smoke test. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>

openshift-ciBot requested review from metacosm and xstefank September 25, 2025 06:57

csviri requested changes Sep 25, 2025
View reviewed changes

csviri mentioned this pull request Sep 25, 2025
Verifying JOSDK with Kotlin #2967
Closed

metacosm changed the title ~~fix: handle all excptions to support Kotlin~~fix: handle all exceptions to support KotlinSep 25, 2025

dvob force-pushed the handle-all-exceptions branch 2 times, most recently from 565ea5a to 9b0bb8bCompare September 25, 2025 07:34

csviri reviewed Sep 25, 2025
View reviewed changes

Comment thread...java/io/javaoperatorsdk/operator/processing/dependent/workflow/AbstractWorkflowExecutor.java

fix: handle all exceptions to support Kotlin
49a913e
Handle Exception and not just RuntimeException to support Kotlin and probably other JVM languages which do not have the concept of checked exceptions.

dvob force-pushed the handle-all-exceptions branch from 9b0bb8b to 49a913eCompare September 25, 2025 07:44

metacosm approved these changes Sep 25, 2025
View reviewed changes

xstefank approved these changes Sep 25, 2025
View reviewed changes

florianknecht mentioned this pull request Sep 25, 2025
Use eventsource for secondary resource by default #2968
Closed

csviri merged commit e368709 into operator-framework:mainSep 25, 2025
1 check failed

exijn mentioned this pull request Jul 25, 2026
test: verify Kotlin interop with a unit test and a Kotlin sample operator E2E test #3513
Merged
3 tasks