[
https://issues.apache.org/jira/browse/FLINK-41242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Metzger reassigned FLINK-41242:
--------------------------------------
Assignee: Santwana Verma
> status.error reports every exception of a failed job as
> `org.apache.flink.util.SerializedThrowable`
> ---------------------------------------------------------------------------------------------------
>
> Key: FLINK-41242
> URL: https://issues.apache.org/jira/browse/FLINK-41242
> Project: Flink
> Issue Type: Bug
> Components: Kubernetes Operator
> Affects Versions: 1.16.1
> Reporter: Santwana Verma
> Assignee: Santwana Verma
> Priority: Minor
>
> When a job fails, the operator fetches the job result and writes its failure
> cause to `status.error.` The JobManager sends that cause as a
> SerializedThrowable, and
> `FlinkResourceExceptionUtils#convertToFlinkResourceException` sets type from
> throwable.getClass().getName(). As a result, type is
> `org.apache.flink.util.SerializedThrowable` for the top-level error and for
> every entry in throwableList, whatever the job actually threw.
> For example, a SQL job that fails while casting 'x1' to INT reports:
> {{{"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":"..."}}}
> {{, ...]}}}
> Tools that read status.error therefore cannot tell exceptions apart by type.
> The operator's own kubernetes.operator.exception.label.mapper only matches
> messages, so it is not affected. The original class name is only available by
> parsing it out of message, because SerializedThrowable's message is the
> original's toString().
> SerializedThrowable already records the original class
> (getOriginalErrorClassName()). The proposed fix is to use it for type, both
> at the top level and in throwableList, when the throwable is a
> SerializedThrowable. message stays as it is, so readers that parse the class
> out of it keep working.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
