apache / apache/airflow

Fix handling AirflowFailException `on_retry_callback`

Open
#60,172 11 comments 0 reactions 0 assignees View on GitHub
affected_version:3.1 area:core good first issue kind:bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.