arkadiuszbach commented on issue #71202: URL: https://github.com/apache/airflow/issues/71202#issuecomment-6146322690
My PR [#69034](https://github.com/apache/airflow/pull/69034) may help here. It is merged into main, but is not included in Airflow 3.3.0–3.3.2. It makes the supervisor perform a warm shutdown on SIGTERM, allowing the running task to continue instead of forwarding the signal and invoking the operator's on_kill(). I reproduced your two-pod deletion example on Airflow 3.3.0 / Task SDK 1.3.0 / Kubernetes provider 10.19.0: the task reported SUCCESS after only 8 of 120 workload ticks. With main at a52e9f96ec, provider 10.24.0 and worker DUMB_INIT_SETSID=0, the supervisor waited, KPO detected the failed child pod, and the task entered UP_FOR_RETRY. The comparison also used newer package versions, so it does not isolate #69034. Could you try applying the Task SDK changes from #69034 to your existing Airflow test deployment, set DUMB_INIT_SETSID=0 in the KubernetesExecutor worker pod template, and rerun your reproduction after restarting the affected Airflow components? You can test the changes on your existing Airflow version without building from main. Please let us know whether this resolves the false SUCCESS in your deployment. -- 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]
