Andrushika opened a new pull request, #76513:
URL: https://github.com/apache/airflow/pull/76513
## Why
When a task starts, the worker calls `ti_run`. The response includes every
asset event that the Dag run consumed, with the asset and the source aliases of
each event. `ti_run` loaded the events together with the Dag run, but not those
two relationships. So building the response queried the database once per event
for the asset, and once more for the aliases.
A Dag with `schedule=[Asset("rare"), Asset("freq")]` collects every `freq`
event until `rare` arrives. With 33,500 queued events on 3.4.0rc2 and Postgres,
each `ti_run` call took 11 to 22 s, which is longer than the 5 s `[workers]
execution_api_timeout`. The task failed before it started, and the run failed.
3.3.2 behaves the same.
## What
The asset and the aliases of the consumed events are now loaded with
`selectinload`, as `callback_requests.py` and the scheduler already do. A run
with no consumed events issues the same queries as before. With the same 33,500
events on the rc2 image, `ti_run` took 4.4 s and the task ran.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Opus 5.5)
Generated-by: Claude Code (Opus 5.5) following [the
guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
--
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]
