afedulov commented on PR #25656: URL: https://github.com/apache/flink/pull/25656#issuecomment-2582320914
> But while debugging the issue I found that the class loader coming here is the App class loader and not the user class loader. In that case the primary question should be - why does the userClassLoader class field not contain the actual user class loader in the first place. Should not that be the focus of the fix instead of pulling it out of the resourceManager only for one the methods? > and I see minimum possibility on regressions. Unfortunately, I can't agree with this assessment. There are thousands of SQL jobs out there that might have unintentionally included some classes that could cause the jobs to fail after we implement this change. For instance, the `flink-avro` format includes an unshaded version of the Avro [library](https://github.com/apache/flink/blob/d9c10d584b7ef8532804b849cfbd2b33beac8044/flink-formats/flink-avro/pom.xml#L81), which is directly [used](https://github.com/apache/flink/blob/85937b8c11dcca25fd978d095d07af121d7ae8e3/flink-formats/flink-avro/src/main/java/org/apache/flink/formats/avro/typeutils/AvroSerializerSnapshot.java#L28) in the core format classes. If the user JAR, for some reason, mistakenly bundles the same library in a different version, those classes would take priority after the change and could potentially break existing jobs. Should those jobs have failed upon the initial submission if the "correct" classloading had been applied? Yes. Can we risk breaking production jobs in a patch release, even by doing the "right" thing? My answer is no. The risk is especially not worth it because the issue has existed since version 1.16 (over 2 years) and is only relevant for the Table API. Moreover, a [workaround](https://issues.apache.org/jira/browse/FLINK-29890?focusedCommentId=17693105&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17693105) exists, and a proper fix is implemented in 2.0. -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
