fix(scheduler): ignore stale executor success after defer reschedule

[Pedrinhonitz]

Summary

Fixes a race where the trigger resumes a deferred task to scheduled before the scheduler processes the executor SUCCESS from the worker defer exit. The scheduler then treated scheduled vs executor success as a state mismatch and failed the TI (#66374).

Changes

• In process_executor_events, treat executor SUCCESS while the TI is SCHEDULED with next_method set (same try) as a stale defer-exit event, consistent with the existing “requeued after defer” intent.
• Add test_process_executor_events_stale_success_when_scheduled_after_defer (positive + negative without next_method).
• Add newsfragment 66374.bugfix.rst.

Testing

pytest airflow-core/tests/unit/jobs/test_scheduler_job.py::TestSchedulerJob::test_process_executor_events_stale_success_when_scheduled_after_defer -q

• closes: Race condition between scheduler processing events and trigger completion #66374

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Cursor following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our prek-hooks will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example Dag that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[jscheffl]

Looks good for me. Thanks for the fix!

As I am not 100% deep in the scheduler feel not comfortable to mege, so if there is a second pair of eyes from reviewer would be cool, else LGTM!

[Pedrinhonitz]

Perfect!

I'm also eagerly awaiting another review and am open to other suggestions for resolving this issue.

Thank you for your review.

[henry3260]

Thanks for your fix! I'm just curious, is it possible that the scheduler picks up the TI very quickly and sets its state to QUEUED? In this case, it seems the scheduler would still mark the TI as FAILED when it receives the stale SUCCESS event.

[eladkal]

Probably needs @ashb eyes to confirm

[ashb]

This entire executor event thing has always been overly complex and confusing.

If the event from the executor is success do we ever need to do anything? If the executor says it ran successfully (which means the "supervisor" ran okay, it says nothing about the task) can't we simply ignore the event? We only need to be concerned with executor failures as the task may not have been able to report it's failure?

[Pedrinhonitz]

I agree that this whole process is difficult to understand. This PR focuses on the false mismatch of issue #66374, which occurs when IT is already scheduled with next_method after the trigger. A more comprehensive approach, such as "ignoring all executor SUCCESSES," would require a check to ensure that each consumer of these events is not unexpectedly affected. I am not entirely familiar with this control and have minimal knowledge about it; this was my first contribution, but your comment about the scheduler not needing to process SUCCESS makes sense to me, as that is the expected behavior.

I apologize for my English. (I'm translating some points that I didn't understand, and I may have misinterpreted something.)

[jscheffl]

@ashb as I assume even if it is hard still OK to merge? I assume this also fixed one erro we had in production after applying the hotfix locally. So I think this is good. At least as a fix. General improvements welcome but would prevent waiting longer.