vsantwana opened a new pull request, #1233:
URL: https://github.com/apache/flink-kubernetes-operator/pull/1233
## What is the purpose of the change
Right now, when a job fails, every `type` in the resource's `status.error`
is `org.apache.flink.util.SerializedThrowable`, at the top level and in each
`throwableList` entry, whatever the job actually threw. For example, a SQL job
that fails while casting `'x1'` to `INT` reports:
```json
{"type":"org.apache.flink.util.SerializedThrowable","message":"org.apache.flink.runtime.JobException:
Recovery is suppressed by
FixedDelayRestartBackoffTimeStrategy(...)","throwableList":[{"type":"org.apache.flink.util.SerializedThrowable","message":"..."},
...]}
```
The JobManager returns the failure cause as a `SerializedThrowable`, and the
operator takes `type` from the Java class of the throwable it holds. Tools that
read `status.error` can only recover the real class by parsing it out of
`message`.
This PR reports the class of the exception the job actually threw, which
`SerializedThrowable` already records. `message` is unchanged, so readers that
parse the class out of it keep working. The change applies to any
`SerializedThrowable` in the reported error and its causes, which in practice
means errors that came from the JobManager; all other exceptions are reported
as before. The `kubernetes.operator.exception.label.mapper` option matches on
messages only, so its labels do not change.
## Brief change log
- When the throwable is a `SerializedThrowable`, `type` now comes from
`SerializedThrowable#getOriginalErrorClassName()`. The JobManager wraps every
cause in the chain as a `SerializedThrowable` too, so the `throwableList`
entries are fixed by the same change.
- The operator writes a job's failure to `status.error` when it sees the
job change to FAILED. A resource whose job had already failed before the
upgrade keeps the old `type` values until the operator records a new error.
Note: this changes the value of `status.error.type` and
`status.error.throwableList[].type` for exceptions that come from the
JobManager, most often a failed job's failure cause. They now hold the original
exception class (for example `org.apache.flink.runtime.JobException`) instead
of `org.apache.flink.util.SerializedThrowable`.
## Verifying this change
This change added tests and can be verified as follows:
- Added
`FlinkResourceExceptionUtilsTest#testSerializedThrowableReportsOriginalType`.
It passes a `SerializedThrowable` that wraps a `FlinkRuntimeException` caused
by a `NumberFormatException`, and checks the top-level `type`, the
`throwableList` types, and that `message` is unchanged. Without the fix it
fails with `expected: <org.apache.flink.util.FlinkRuntimeException> but was:
<org.apache.flink.util.SerializedThrowable>`; with the fix all 7 tests in the
class pass.
- `mvn clean verify` passes locally (2935 tests). I excluded
`RestApiMetricsCollectorTest` in `flink-autoscaler` from that run, because it
needs port 8081 and another process on my machine was holding it. That module
does not use the changed code.
- Not run: an end-to-end check with a failing job on minikube.
## Does this pull request potentially affect one of the following parts:
- Dependencies (does it add or upgrade a dependency): no
- The public API, i.e., is any changes to the `CustomResourceDescriptors`:
no (the CRD schema is unchanged; only the content of `status.error.type`
changes)
- Core observer or reconciler logic that is regularly executed: yes (the
job status observer uses this code to write `status.error` when a job fails;
only the reported `type` changes)
## Documentation
- Does this pull request introduce a new feature? no
- If yes, how is the feature documented? not applicable
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Claude Opus 5.5)
--
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]
