DianaHov opened a new issue, #73152:
URL: https://github.com/apache/airflow/issues/73152
### Under which category would you file this issue?
Airflow Core
### Apache Airflow version
3.3.1
### What happened and how to reproduce it?
Marking a Dag run as success or failed from the UI returns `409 Conflict`
("Update Dag Run Request Failed"), but the change is applied anyway - the run
and its task instances are updated, and the UI shows an error for an
operation
that actually succeeded.
It only happens the **first** time a given run is marked. Marking the same
run
again succeeds with no error.
The api-server log shows:
`Error with id ..., statement: INSERT INTO dag_run_note
(user_id, dag_run_id, content, created_at, updated_at) VALUES (...)`
i.e. a duplicate-key violation on `dag_run_note`, surfaced as 409 by
`_UniqueConstraintErrorHandler`. It happens even with the Note field left
empty.
Works correctly in 3.3.0.
To reproduce:
1. Fresh 3.3.1 install, Postgres, any Dag.
2. Trigger a run and leave it un-started.
3. Mark the run as success (or failed) from the UI, leaving the Note box
empty.
4. The red "Conflict" toast appears; the run is nevertheless marked and its
task instances updated.
5. Mark the same run again - this time it succeeds silently.
### What you think should happen instead?
The request should return 200 and no duplicate insert should be attempted.
---
The cause is the note/state ordering in `patch_dag_run`
(`airflow-core/src/airflow/api_fastapi/core_api/routes/public/dag_run.py`),
which is the only change to that function between 3.3.0 and 3.3.1:
```python
# Apply "note" before "state" so listeners fired inside
patch_dag_run_state() see the updated note.
if "note" in data:
...patch_dag_run_note(...)
if "state" in data and patch_body.state is not None:
...patch_dag_run_state(...)
```
With the note applied first, a pending `DagRunNote` is attached to the DagRun
before `patch_dag_run_state()` runs, and the same row ends up inserted twice
within the request — one insert commits (hence the state change taking
effect,
and the row existing afterwards), the second violates `dag_run_note_pkey`.
Once a `dag_run_note` row exists, `patch_dag_run_note()` takes its UPDATE
branch, which is why only the first mark on a given run fails.
Restoring the 3.3.0 order resolves it, but that would undo the
listener-visibility behaviour the reordering was made for.
### Operating System
macOS
### Deployment
Other
### 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
_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]
