anzinmhd opened a new issue, #75245:
URL: https://github.com/apache/airflow/issues/75245

   ### Under which category would you file this issue?
   
   Airflow Core
   
   ### Apache Airflow version
   
   3.4.0b1; also reproduced on main
   
   ### What happened and how to reproduce it?
   
   Clicking **Confirm** in the **Clear Task Instance** dialog causes it to 
briefly disappear and reopen. The selected task is not cleared or rerun, and 
its try number remains unchanged.
   
   I reproduced this on main and in a separate deployment using the official 
`apache/airflow:3.4.0b1` image. I observed the behavior in both Safari and 
Chrome.
   
   ### Reproduction Dag
   
   ```python
   from datetime import datetime, timezone
   from time import sleep
   
   from airflow.sdk import DAG, task
   
   with DAG(
       dag_id="reproduce_clear_task_dialog",
       schedule=None,
       start_date=datetime(2026, 1, 1, tzinfo=timezone.utc),
       catchup=False,
       tags=["reproduction", "clear-dialog"],
   ) as dag:
   
       @task
       def wait_seconds(seconds: int):
           sleep(seconds)
   
       a = wait_seconds.override(task_id="A")(3)
       b = wait_seconds.override(task_id="B")(30)
       c = wait_seconds.override(task_id="C")(3)
   
       a >> b >> c
   ```
   
   ### Steps to reproduce
   
   1. Deploy the Dag, enable it, and trigger a run.
   2. Wait until A, B, and C have succeeded.
   3. Open the completed run's Task Instances tab.
   4. Click the clear action for task C.
   5. Ensure only C is selected. Leave Past, Future, Upstream, Downstream, and 
Clear only failed tasks unselected.
   6. Leave **Prevent rerun if task is running** checked and **Keep task state 
and resume** unchecked.
   7. Click **Confirm**.
   
   ### Actual result
   
   The dialog flickers and reopens instead of completing the clear action. Task 
C remains successful with its original try number.
   
   In the captured failed interactions, requests to
   `POST /api/v2/dags/{dag_id}/clearTaskInstances` return HTTP 200 with
   `dry_run: true` in their request payloads. No request with `dry_run: false`
   was observed.
   
   The attached recording shows the dialog behavior, a request payload with
   `dry_run: true`, and the unchanged try number afterward.
   
   
https://github.com/user-attachments/assets/a050ca19-d1a6-417b-89af-20d5c80b06ae
   
   ### What you think should happen instead?
   
   Confirming the clear action should send the actual clear request and close 
the dialog after it succeeds. With the scheduler running and dependencies 
satisfied, task C should rerun and its try number should increase.
   
   ### Operating System
   
   macOS host, with Airflow running in Linux Docker containers.
   
   ### Deployment
   
   Docker-Compose
   
   ### Apache Airflow Provider(s)
   
   _No response_
   
   ### Versions of Apache Airflow Providers
   
   _No response_
   
   ### Official Helm Chart version
   
   Not Applicable
   
   ### Kubernetes Version
   
   _No response_
   
   ### Helm Chart configuration
   
   _No response_
   
   ### Docker Image customizations
   
   The beta reproduction used the official apache/airflow:3.4.0b1 image with a 
mounted reproduction Dag and local configuration. Main was tested using Breeze.
   
   ### Anything else?
   
   Sending a clear request directly with dry_run: false successfully reruns the 
task.
   
   The behavior was observed in both Safari and Chrome. The attached recording 
shows the failed UI interaction and a request payload containing dry_run: true.
   
   ### Are you willing to submit 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)
   


-- 
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]

Reply via email to