potiuk commented on PR #27887: URL: https://github.com/apache/airflow/pull/27887#issuecomment-1337636376
Hey here - just that we do not forget https://apache-airflow.slack.com/archives/CCQ7EGB1P/p1670254804118349 - is an interesting thread that traces back to this change. While I understand the reasoning, this leads to a backwards incompatible behaviour that has potentially quite disruptive behaviours - i.e. anyone who returns a custom class from their operator hits this error: ``` ImportError: Foo was not found in allow list for import ``` I uunderstand it can be fixed by adding full class specification to https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html#allowed-deserialization-classes but I am not sure if we are prepared for a number of user hitting similar issue (it has potential of breaking many workflows IMHO). It can be classified as a security fix, so I am pretty ok to have it in 2.5.0 and treated as "non-breaking" behaviour, but I am wondering if this was intention and if so, whether we should not add a more explanatory message ? WDYT everyone? -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
