There is still one case in Airflow 3, where the _on_task_instance_* listener method is being called on scheduler and as a result, is using DB TaskInstance model instead of RuntimeTaskInstance. The call is here, when external task state change is being handled, the ti.fetch_handle_failure_context is calling get_listener_manager().hook.on_task_instance_failed. Currently, for complete/fail listener methods, for DB TaskInstance model, we're calling the _on_task_instance_manual_state_change path, which is generally correct, as it does not call any user code (as opposed to _on_task_instance_success and _on_task_instance_failed that may call user custom run facets function and operator OL method). So to correctly handle this scheduler call, I've kept it as manual state change (we should maybe rename it to external, but it's still relevant) and I just added some checks that will create airflowrunfacet in that scenario, since we have all the models there (we still don't on api server). Added appropriate comments and tests.

So TLDR; when task state is externally changed the event will be emitted from scheduler as it is now but with additional AirflowRunFacet when possible.

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

• Yes (please specify the tool below)

• 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 or {issue_number}.significant.rst, in airflow-core/newsfragments.