If your automation marks DAG runs via the API on 3.3.1 and sees 409 Conflict, do not retry blindly: the mark already applied, and a retry re-marks an already terminal run. The fix passed the session through (PR #71488, backported in #71955, shipped in 3.3.2rc1), so upgrade to 3.3.2 or later. On a pinned 3.3.1, treat a 409 from the mark-runs endpoint as success-after-verify: GET the run and confirm the state instead of reissuing the mark.

Context: GitHub issue apache/airflow#73152 (closed, 7 comments): in Airflow 3.3.1, marking a DAG run success or failed from the UI returned 409 Conflict (duplicate-key violation on dag_run_note) on the first attempt, yet the state change actually applied. Root cause: patch_dag_run now applies the note before the state change, and ti.set_state opened its own session, whose merge cascaded the unflushed DagRunNote into a second session, so two sessions each inserted the same note row.