[raghavan-arvind]

What

Follow-up to #66431 and #68741: extends the resume-after-defer guard in _process_executor_events to the running state, for triggers that fire immediately after deferral because scheduler has processed success event from executor.

Why

Ran into the following issue today, timeline from audit log:

• 2026-08-13 18:25:07 - running
• 2026-08-13 18:25:13 - deferred
• 2026-08-13 18:25:18 - running
• 2026-08-13 18:25:20 - state mismatch - Executor LocalExecutor(parallelism=200) reported that the task instance <TaskInstance: DAG.TASK__2026-08-13T15:00:00+00:00 [running] ti_id=019ffd71-91ba-7380-865a-671e464f41ee> finished with state success, but the task instance's state attribute is running. Learn more: https://airflow.apache.org/docs/apache-airflow/stable/troubleshooting.html#task-state-changed-externally
• 2026-08-13 18:25:20 - failed

Inline with the previous few changes to handle the race for tasks already in the scheduled and queued states. If the task is running, we want to handle the same way, allow the triggerer to finish the task instead of killing it.

Test

Expand the previous tests to ensure tasks in the running state are handled correctly. All three tests are testing the same thing -- collapse them and parameterize over the resumed state. Relying on unit tests + intuition based on the observed audit logs above.

AI Disclosure

Used AI to help write the PR. Description written by hand.

Closes #71580.

[raghavan-arvind]

cc: @ashb from #66431, another one in the chain :(. I wonder if we want to just drop the event entirely if state == SUCCESS and next_method is not None (i.e. deferred), at this point, this event has nothing to do with the status of this task. We could also keep parity with above, add "RESTARTING" to this block as well.

[Pedrinhonitz]

Just for the record, I’m leaving my question here as well.

Can we guarantee that the combination of RUNNING and next_method != None never corresponds to a legitimate success result from the current attempt's executor?

If that is the case, we could simply ignore the wrong execution.

Wouldn't it be more robust to consider an alternative that uses an ID associated with the execution? I provided more details on this in #72767

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.