manipatnam opened a new issue, #61700:
URL: https://github.com/apache/airflow/issues/61700
### Apache Airflow version
3.1.7
### If "Other Airflow 3 version" selected, which one?
_No response_
### What happened?
When max_active_tis_per_dag=1 is set on a DAG:
- If a task instance enters the deferred state (e.g. via deferrable
operators),
- A second task instance of the same task is still allowed to be queued,
- Even though the first task instance has not yet completed.
I’ve observed this behavior in both Airflow 2 and Airflow 3.
### What you think should happen instead?
My expectation was that max_active_tis_per_dag would prevent any additional
task instances from being queued or run while an existing one is active —
including those in the deferred state.
### How to reproduce
- Create a DAG with:
- `max_active_tis_per_dag=1`
- At least one **deferrable operator** (for example, a deferrable
sensor).
- Trigger a DAG run and allow the task instance to enter the **deferred**
state.
- While the first task instance is still in the **deferred** state, trigger
one or more additional DAG runs.
- Observe that:
- A new task instance is created for the subsequent DAG run.
- The new task instance transitions to **running** and then **deferred**,
- Even though `max_active_tis_per_dag` is set to `1` and an existing
task instance has not yet completed.
### Operating System
Debian
### Versions of Apache Airflow Providers
_No response_
### Deployment
Astronomer
### Deployment details
_No response_
### Anything else?
_No response_
### Are you willing to submit PR?
- [ ] 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)
--
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]
