John Lonergan commented on FLINK-13588:

Don't agree.

If there is context then the code should not throw it away. Principal.

Without the exception message I cannot discover why the split failed.

For example we had a failure because of a zero byte avro file in hdfs. The
error message had the filename in it but the code throws it away.

As a result we had to write and run a separate trivial job that brute
forced reading all the files (100k) without flinks help.

The change is justified.
I don't think it's reasonable to throw this away. It looks like the error
handling /logging is a bit inconsistent for sure.

We are now running with a modified version of this class that wraps the
original exception into a runtime exception that includes the cause text.

> StreamTask.handleAsyncException throws away the exception cause
> ---------------------------------------------------------------
>                 Key: FLINK-13588
>                 URL: https://issues.apache.org/jira/browse/FLINK-13588
>             Project: Flink
>          Issue Type: Bug
>    Affects Versions: 1.8.1
>            Reporter: John Lonergan
>            Priority: Major
> Code below throws the reason 'message' away making it hard to diagnose why a 
> split has failed for instance.
> {code:java}
> https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/runtime/tasks/StreamTask.java#L909
> @Override
>       public void handleAsyncException(String message, Throwable exception) {
>       if (isRunning) {
>       // only fail if the task is still running
>       getEnvironment().failExternally(exception);
>       }
> }{code}
> Need to pass the message through so that we see it in logs please.

This message was sent by Atlassian JIRA

Reply via email to