Fix handling AirflowFailException `on_retry_callback`
- Dominant language
- Python
- Stars
- 46.9k
- Forks
- 17.8k
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 483
Description
### Description
This was previously possible in Airflow 2 using [this solution](https://github.com/apache/airflow/discussions/28263#discussioncomment-4354509). However, in Airflow 3 `RuntimeTaskInstanceProtocol` does not expose a method for modifying the task state directly.
My suggestion would be to create a new exception type that can be raised from `on_retry_callback` to request a state change to either success or failure.
Update: While this is not specified, it seema a bug that it does not work that way: AirflowFailException raised in `on_retry_callback` or any other state-change callback should immediately fail the task.
### Use case/motivation
We have some long-running tasks (>24hr) that sometimes fail fast due to transient issues. We want to be able to retry whenever these fast fails occur. However, if a failure occurs hours into the task, we would prefer not to retry, as the task must be completed by a certain time and failures of this sort typically represent an actual issue we want to look into.
### Related issues
Just the discussion item [here](https://github.com/apache/airflow/discussions/28263) from years ago as far as I can tell.
### Are you willing to submit a PR?
- [x] Yes I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)
Contributor guide
Research direction
Start by tracing how Airflow 3 handles AirflowFailException and other exceptions raised from on_retry_callback or state-change callbacks, with attention to RuntimeTaskInstanceProtocol. Determine the intended state-transition behavior from the issue and add regression coverage for the callback cases. Done means the callback can cause the task to fail immediately while preserving the expected retry behavior for fast task failures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100