hkc-8010 opened a new issue, #67707: URL: https://github.com/apache/airflow/issues/67707
### Apache Airflow version 3.1.8 ### If "Other Airflow 2 version" selected, which one? Also compared against 2.11.0 ### What happened? We are seeing a behavior difference between Airflow 2 and Airflow 3 when a failed task is manually marked `success` from the **Task Instances view**. Observed versions: - Airflow 2.11.0+astro.4 - Airflow 3.1.8+astro.1 Observed behavior: - In Airflow 2, if a failed task is marked `success` from the **Task Instances view** (`Browse -> Task Instances`), downstream tasks that are currently in `upstream_failed` remain untouched and do **not** resume unless they are explicitly cleared. - In Airflow 3, if a failed task is marked `success` from the **Task Instances view**, downstream tasks can resume within the same `DagRun`. This is especially confusing because in Airflow 2 there was already a difference between: - the DAG/Grid "Mark as success" path, and - the Task Instances view "Set state to success" path. From source review, the older Airflow 2 Task Instances view used a direct `ti.set_state(...)` path, while the DAG/Grid action used `dag.set_task_instance_state(...)`, which also clears downstream failed / `upstream_failed` tasks. Airflow 3's current Task Instance action path appears to follow the `dag.set_task_instance_state(...)` behavior. So the practical result for users migrating from Airflow 2 is: - Airflow 2 Task Instances view: mark success changes only the selected TI state. - Airflow 3 Task Instances view: mark success can resume downstream tasks in the same `DagRun`. This may be an intentional parity change with the DAG/Grid path, but if so it is a significant behavior change for users who relied on the old Task Instances view semantics. ### What do you think should happen instead? At minimum, the behavior should be made explicit and consistent. The ideal outcome would be one of these: 1. Restore the old Task Instances view behavior so that "mark success" only updates the selected task instance and does not resume downstream `upstream_failed` tasks automatically. 2. Add an explicit option in the Task Instances view that lets the user choose whether downstream failed / `upstream_failed` tasks should be resumed. 3. If the current Airflow 3 behavior is intentional, document it clearly as a behavioral change from Airflow 2 so migrations are not surprised by it. ### How to reproduce A simple reproduction is: 1. Create a DAG with at least one upstream task and one downstream task. 2. Cause the upstream task to fail so the downstream task lands in `upstream_failed`. 3. From the Task Instances view, mark the failed upstream task as `success`. 4. Compare behavior between Airflow 2.11.0 and Airflow 3.1.8. What we observe: - Airflow 2.11.0 Task Instances view: downstream `upstream_failed` tasks remain untouched. - Airflow 3.1.8 Task Instances view: downstream tasks can resume within the same `DagRun`. ### Operating System Linux / Kubernetes ### Versions of Apache Airflow Providers _No response_ ### Deployment Other ### Deployment details Compared on Astro-based deployments, but the behavior difference appears to come from Airflow UI/backend action paths rather than deployment-specific infrastructure. ### Anything else? Related issues: - #39362 describes the older inconsistency between Airflow 2 Task Instances view and DAG detail view. - #54779 is related to mapped task restart behavior, but it does not appear to be the same root issue as this Task Instances view behavior change. The main ask here is to clarify whether Airflow 3 Task Instances behavior is intentionally different from Airflow 2, and if so whether an explicit UX control or documentation update is planned. ### 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 -- 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]
