uplsh580 commented on issue #65818: URL: https://github.com/apache/airflow/issues/65818#issuecomment-5212428542
Following up on my [earlier comment](https://github.com/apache/airflow/issues/65818#issuecomment-4525328884): we hit the same deadlock again on 2026-08-06, now on **Airflow 3.2.2** — same single-row UPDATE through the `Trigger.submit_event` → `handle_event_submit` path, and the triggerer process died, causing a container restart (the pod itself stayed up). @fedemgp to answer your question: no — I think 3.2.2 does not fix this. #66412 addresses the comms-channel race inside the triggerer (lock-based serialization → response multiplexing), which is unrelated to this MySQL row-lock deadlock on `task_instance`. We can confirm it still reproduces on 3.2.2. Environment - Airflow 3.2.2 - MySQL (InnoDB) - triggerer replicas: 2 - Workload: deferrable operators (YARN/Spark application completion event) Failing statement UPDATE task_instance SET state='scheduled', scheduled_dttm=..., updated_at=..., trigger_id=NULL, next_kwargs=... WHERE task_instance.id = '019fd7e27e377324a5f4536ed6640510' → MySQLdb.OperationalError: (1213, 'Deadlock found when trying to get lock; try restarting transaction') Stack (3.2.2) airflow/jobs/triggerer_job_runner.py:218 _execute airflow/jobs/triggerer_job_runner.py:612 run airflow/jobs/triggerer_job_runner.py:655 handle_events airflow/models/trigger.py:274 submit_event airflow/models/trigger.py:505 handle_event_submit → session.flush() One additional detail compared to our previous occuer process did not terminate on SIGINT/SIGTERM afterthe exception and had to be SIGKILLed by the supervisor (`Process exited exit_code=-9 signal_sent=SIGKILL`), so triggers thstill running at that point were interrupted mid-fle other replica picked them up), but the restart isnoisy at the alerting level.On 3.2.2 the call chain (`handle_events` → `submit_mit`) still has no `@retry_db_transaction` orequivalent, so a single transient 1213 kills the whix PRs for the bulk-UPDATE paths (#65836, #65920)have gone stale, I'd propose wrapping this per-evennsaction` (matching the existing scheduler-sidepattern) as an incremental fix — it wouldn't removef, but it would stop a single transient deadlock from taking down the triggerer. I'll put up a PR along t -- 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]
