Delete dag run endpoint returns 204 even if run could not be deleted

[DataCerealz]

Apache Airflow version

Other Airflow 3 version (please specify below)

If "Other Airflow 3 version" selected, which one?

3.1.3

What happened?

We call delete on the dag run endpoint of the airflow REST api for two dag run ids from within a task.
The API returns 204 successfully.

One dag run was in state "queued" and got deleted. The other dag run was in state "running" and thus was not deleted. In both cases the return status is 204.

What you think should happen instead?

If attempting to delete a dag run that is not in DAGRunPatchStates, indicate in the response that the delete request was denied / could not be performed instead of giving the impression to users that the delete was performed successfully.

How to reproduce

Run a dag. Note the run id. Try to call delete on the dag run endpoint while the dag run is still in the "running" state.

Operating System

Debian

Versions of Apache Airflow Providers

No response

Deployment

Astronomer

Deployment details

Astro Runtime 3.1-5; k8s

Anything else?

The open api documentation also does not mention which states the delete call is actually able / supposed to delete. So without going into the source code it's rather hard to tell for new users.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

I would be willing to; but am too uncertain as towards the "how". The first fix that would come to mind for me is actually adding state validation to the delete_dag_run function in airflow/api_fastapi/core_api/routes/public/dag_run.py. I am just hesitant to do so because it adds the db calls to a session and only if the session gets flushed it attempts to write the changes. So technically if I'd have the validation up front, I might reject a call that would have maybe succeeded a second later when the flush happens and the state turned into a DAGRunPatchStates member in the meantime, right? Probably that's of no concern; but I kind of feel like I can't just impose such a decision as a first time contributor. If implementation guidance/decisions is given I am happy to contribute some code though.

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[justinpakzad]

Hey, been taking a look at this one. I went ahead and tried to reproduce your example by deleting a specific dag run while it was in a "running" state via API and for me the dag run got deleted. I did notice the delete dag endpoint doesn't allow you to delete a running dag, wonder if the delete dag run endpoint should mimic that behavior or maybe it was intentional.

[Arunodoy18]

This PR addresses the case where the DELETE /dagRuns endpoint returns 204 even when a DAG run in a non-deletable state (e.g. running) is not actually deleted. It adds explicit state validation to make the API behavior clearer and avoid giving users a false impression of success. I’m happy to adjust the approach or placement of this validation based on maintainer guidance.

[justinpakzad]

Haven't seen a PR for this in a bit so I'm going to take it if that's cool. Cheers