potiuk edited a comment on issue #20797: URL: https://github.com/apache/airflow/issues/20797#issuecomment-1009851004
I don't see anything ironic in it when I consider the architectire of Airflow and the way it works - especially in order to achieve resilency and robustness. I believe that the main reason is that we cannot know sometimes what were the args. When they are dynamically passed (and potentially calculated via jinja templates when PythonOperator gets execute() method called. But for example, when Python operators fail because it is forcefully killed or forcefully (via UI) set to "success" state, the callbacks will be executed in the DagProcessor/Scheduler - not in the worker/task where the execute() method has been called. I believe at that point the op_kwars and op_args are not (easily) available. I am not sure if those args can be easily passed in this case. If there are others who confirm that - by all means please make PR to update the documentation menioning that. Airlfow has almost 1900 contributors and documentation from the users who - like you might have different assumptions or lack the broader context of how Airflow works under the hood. And such users are the best to find and document those assumptions and choices in the place that will be most likely best for other users with similar needs. -- 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]
