[ 
https://issues.apache.org/jira/browse/FLINK-41242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated FLINK-41242:
-----------------------------------
    Labels: pull-request-available  (was: )

> 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
>              Labels: pull-request-available
>
> 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)

Reply via email to