[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flink Jira Bot updated FLINK-14174: --- Labels: auto-deprioritized-major stale-minor (was: auto-deprioritized-major) I am the [Flink Jira Bot|https://github.com/apache/flink-jira-bot/] and I help the community manage its development. I see this issues has been marked as Minor but is unassigned and neither itself nor its Sub-Tasks have been updated for 180 days. I have gone ahead and marked it "stale-minor". If this ticket is still Minor, please either assign yourself or give an update. Afterwards, please remove the label or in 7 days the issue will be deprioritized. > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Minor > Labels: auto-deprioritized-major, stale-minor > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > Recorded as a bug because this "helpful hint" masks exceptions and is > sometimes a complete red herring and in my case wasted a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the cost/benefit of the "helpful hint" introduced by > FLINK-4663 for two reasons > - it can be a red herring - in mine case and also and [at least one other > person > |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception] > - I don't agree with ever throwing away or masking causal exceptions - these > must always be propagated (I raised a similar issue in my previous > contribution) > > My suggestion is to either back out FLINK-4663 so that we get to see the raw > underlying exception and call stack -or- come up with a way to distinguish > the specific case "FLINK-4663" was attempting to cover and only emit that > hint hint if the specific case is encountered. > For all other cases the helpful hint should not be emitted. > And - regardless of whether the helpful hint it emitted or not +the causal > exception must always be propagated+. > My vote is to back out FLINK-4663 and maybe add some logging instead. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flink Jira Bot updated FLINK-14174: --- Labels: auto-deprioritized-major (was: stale-major) > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > Labels: auto-deprioritized-major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > Recorded as a bug because this "helpful hint" masks exceptions and is > sometimes a complete red herring and in my case wasted a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the cost/benefit of the "helpful hint" introduced by > FLINK-4663 for two reasons > - it can be a red herring - in mine case and also and [at least one other > person > |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception] > - I don't agree with ever throwing away or masking causal exceptions - these > must always be propagated (I raised a similar issue in my previous > contribution) > > My suggestion is to either back out FLINK-4663 so that we get to see the raw > underlying exception and call stack -or- come up with a way to distinguish > the specific case "FLINK-4663" was attempting to cover and only emit that > hint hint if the specific case is encountered. > For all other cases the helpful hint should not be emitted. > And - regardless of whether the helpful hint it emitted or not +the causal > exception must always be propagated+. > My vote is to back out FLINK-4663 and maybe add some logging instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flink Jira Bot updated FLINK-14174: --- Priority: Minor (was: Major) > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Minor > Labels: auto-deprioritized-major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > Recorded as a bug because this "helpful hint" masks exceptions and is > sometimes a complete red herring and in my case wasted a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the cost/benefit of the "helpful hint" introduced by > FLINK-4663 for two reasons > - it can be a red herring - in mine case and also and [at least one other > person > |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception] > - I don't agree with ever throwing away or masking causal exceptions - these > must always be propagated (I raised a similar issue in my previous > contribution) > > My suggestion is to either back out FLINK-4663 so that we get to see the raw > underlying exception and call stack -or- come up with a way to distinguish > the specific case "FLINK-4663" was attempting to cover and only emit that > hint hint if the specific case is encountered. > For all other cases the helpful hint should not be emitted. > And - regardless of whether the helpful hint it emitted or not +the causal > exception must always be propagated+. > My vote is to back out FLINK-4663 and maybe add some logging instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flink Jira Bot updated FLINK-14174: --- Labels: stale-major (was: ) > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > Labels: stale-major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > Recorded as a bug because this "helpful hint" masks exceptions and is > sometimes a complete red herring and in my case wasted a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the cost/benefit of the "helpful hint" introduced by > FLINK-4663 for two reasons > - it can be a red herring - in mine case and also and [at least one other > person > |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception] > - I don't agree with ever throwing away or masking causal exceptions - these > must always be propagated (I raised a similar issue in my previous > contribution) > > My suggestion is to either back out FLINK-4663 so that we get to see the raw > underlying exception and call stack -or- come up with a way to distinguish > the specific case "FLINK-4663" was attempting to cover and only emit that > hint hint if the specific case is encountered. > For all other cases the helpful hint should not be emitted. > And - regardless of whether the helpful hint it emitted or not +the causal > exception must always be propagated+. > My vote is to back out FLINK-4663 and maybe add some logging instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Lonergan updated FLINK-14174: -- Description: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. Recorded as a bug because this "helpful hint" masks exceptions and is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack -or- come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. was: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. Recorded as a bug because this "helpful hint" masks exceptions and is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception ] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack -or- come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > Recorded as a bug because this "helpful hint" masks exceptions and is > sometimes a complete red herring and in my case wasted a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Lonergan updated FLINK-14174: -- Description: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. Recorded as a bug because this "helpful hint" masks exceptions and is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception ] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack -or- come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. was: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. This "helpful hint" is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception ] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack -or- come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > Recorded as a bug because this "helpful hint" masks exceptions and is > sometimes a complete red herring and in my case wasted a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Lonergan updated FLINK-14174: -- Issue Type: Bug (was: Improvement) > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Bug > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > This "helpful hint" is sometimes a complete red herring and in my case wasted > a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the cost/benefit of the "helpful hint" introduced by > FLINK-4663 for two reasons > - it can be a red herring - in mine case and also and [at least one other > person > |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception > ] > - I don't agree with ever throwing away or masking causal exceptions - these > must always be propagated (I raised a similar issue in my previous > contribution) > > My suggestion is to either back out FLINK-4663 so that we get to see the raw > underlying exception and call stack -or- come up with a way to distinguish > the specific case "FLINK-4663" was attempting to cover and only emit that > hint hint if the specific case is encountered. > For all other cases the helpful hint should not be emitted. > And - regardless of whether the helpful hint it emitted or not +the causal > exception must always be propagated+. > My vote is to back out FLINK-4663 and maybe add some logging instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Lonergan updated FLINK-14174: -- Description: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. This "helpful hint" is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception ] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack -or- come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. was: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. This "helpful hint" is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception ] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack or come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Improvement > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > This "helpful hint" is sometimes a complete red herring and in my case wasted > a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the
[jira] [Updated] (FLINK-14174) Don't swallow exception when rethrowing type mismatches with side outputs
[ https://issues.apache.org/jira/browse/FLINK-14174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Lonergan updated FLINK-14174: -- Description: The change made by https://github.com/apache/flink/pull/4663/files introduces a "helpful hint" that a class cast at that location might be due a Flink pipeline cfg error and the code goes onto swallows the original exception and masked a protocol buffer serialisation problem we were having. This "helpful hint" is sometimes a complete red herring and in my case wasted a lot of peoples time. In my case I had a class cast error in some proto serialisation code and because the "helpful hint" traps ClassCastException I wasn't able to discover the error easily. In the end we modified the Flink distribution to remove this "helpful hint" at which point the real error was found and we quickly fixed it - but not without a lot of burned time. I am not convinced of the cost/benefit of the "helpful hint" introduced by FLINK-4663 for two reasons - it can be a red herring - in mine case and also and [at least one other person |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception ] - I don't agree with ever throwing away or masking causal exceptions - these must always be propagated (I raised a similar issue in my previous contribution) My suggestion is to either back out FLINK-4663 so that we get to see the raw underlying exception and call stack or come up with a way to distinguish the specific case "FLINK-4663" was attempting to cover and only emit that hint hint if the specific case is encountered. For all other cases the helpful hint should not be emitted. And - regardless of whether the helpful hint it emitted or not +the causal exception must always be propagated+. My vote is to back out FLINK-4663 and maybe add some logging instead. was: The change made by https://github.com/apache/flink/pull/4663/files swallows the original exception. Whilst I am in favour of adding additional helpful tips (which was the purpose of FLINK-4663) I don't agree with throwing away or masking causal exceptions. IMHO the correct approach is to add the helpful hint as the first arg to "new ExceptionInChainedOperatorException(msg, ex)" and pass the original class cast ex as the cause. Ie change this .. https://github.com/apache/flink/blob/master/flink-streaming-java/src/main/java/org/apache/flink/streaming/runtime/tasks/OperatorChain.java#L672 > Don't swallow exception when rethrowing type mismatches with side outputs > - > > Key: FLINK-14174 > URL: https://issues.apache.org/jira/browse/FLINK-14174 > Project: Flink > Issue Type: Improvement > Components: API / DataStream >Affects Versions: 1.8.1, 1.9.0 >Reporter: John Lonergan >Priority: Major > > The change made by https://github.com/apache/flink/pull/4663/files introduces > a "helpful hint" that a class cast at that location might be due a Flink > pipeline cfg error and the code goes onto swallows the original exception and > masked a protocol buffer serialisation problem we were having. > This "helpful hint" is sometimes a complete red herring and in my case wasted > a lot of peoples time. > In my case I had a class cast error in some proto serialisation code and > because the "helpful hint" traps ClassCastException I wasn't able to discover > the error easily. In the end we modified the Flink distribution to remove > this "helpful hint" at which point the real error was found and we quickly > fixed it - but not without a lot of burned time. > I am not convinced of the cost/benefit of the "helpful hint" introduced by > FLINK-4663 for two reasons > - it can be a red herring - in mine case and also and [at least one other > person > |https://stackoverflow.com/questions/56069797/multiple-outputtags-in-stream-process-function-with-classcastexception > ] > - I don't agree with ever throwing away or masking causal exceptions - these > must always be propagated (I raised a similar issue in my previous > contribution) > > My suggestion is to either back out FLINK-4663 so that we get to see the raw > underlying exception and call stack or come up with a way to distinguish the > specific case "FLINK-4663" was attempting to cover and only emit that hint > hint if the specific case is encountered. > For all other cases the helpful hint should not be emitted. > And - regardless of whether the helpful hint it emitted or not +the causal > exception must always be propagated+. > My vote is to back out FLINK-4663 and maybe add some logging instead. -- This message was sent by Atlassian Jira (v8.3.4#803005)
