[ccoliu]

Part of #76425 (the GET /api/v2/dags item, plus the other list routes with the same shape).

GET /dags, PATCH /dags and the UI GET /dags/{dag_id}/dagRuns/{dag_run_id}/deadlines passed ORM rows into an Iterable[...] response field. Pydantic validates Iterable items lazily, while FastAPI serializes the response on the event loop, so each Dag's tags (and, with [core] multi_team = True, each Dag run's team) were loaded there, on the sync engine. Once the connection pool is busy, that blocks the whole API server.

Following #74247, the collection fields are now list[...] and the routes validate the rows themselves, so the loads run in the threadpool with the rest of the route. PATCH /dags also eager-loads the tags with selectinload, as GET /dags already does, so they aren't loaded one Dag at a time.

How I found the affected routes

Rather than going by the shape of the code, I ran the existing tests of every list route (public/test_dags.py, test_connections.py, test_variables.py, test_dag_versions.py, test_dag_warning.py, test_pools.py, test_backfills.py, test_dag_run.py, test_task_instances.py, test_xcom.py, test_event_logs.py, test_import_error.py, test_job.py, test_assets.py, test_dag_bundles.py, test_hitl.py, ui/test_deadlines.py) with a plugin that records every statement executed on the event loop thread, the same check as the event_loop_queries fixture. Leaving out the async-engine audit log writes and the authorization lookups already tracked in #76425, the only remaining list-route hits were these three. Several of the other list routes pass the same unconsumed ScalarResult, but nothing is left to query while they serialize: the route either eager-loads with joinedload or builds the items first, or the response model reads columns only.

Tests

• New regression tests use event_loop_queries: test_get_dags_should_not_query_on_event_loop, test_patch_dags_should_not_query_tags_on_event_loop and, for deadlines in multi-team mode, test_should_not_query_on_event_loop. All three fail without the fix, each listing the dag_tag or team query that ran on the loop.
• With the fix, public/test_dags.py, ui/test_deadlines.py, ui/test_dags.py and ui/test_calendar.py pass (373 passed, 6 skipped), and the recording plugin reports no non-audit statements on the event loop for them.
• The JSON schema of DAGCollectionResponse and DeadlineCollectionResponse is unchanged (Iterable and list both render as an array), so the generated OpenAPI spec and UI client don't change.

The PATCH /dags test only checks for dag_tag statements, since action_logging writes the audit log on the event loop through the async engine, which doesn't block it.

---

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

• Yes — Claude Code (Claude Opus 5.5)

Generated-by: Claude Code (Claude Opus 5.5) following the guidelines

[henry3260]

I think the PR description might mislead others. The last line of "How I found the
affected routes" says the other collection routes fetch their rows inside the route and
have no lazy relationships in their response models. But several of them pass the same
unconsumed ScalarResult as the three fixed here, and a few of those models do read a
relationship (dag_display_name through AliasPath("dag_model", ...)). What keeps them
off the loop is the route: joinedload, or building the items first, or a column-only
model.

Maybe reword it as:

Several of the other list routes pass the same unconsumed ScalarResult, but nothing is
left to query while they serialize: the route either eager-loads with joinedload or
builds the items first, or the response model reads columns only.

[henry3260]

Thanks for the PR!

[ccoliu]

I think the PR description might mislead others. The last line of "How I found the affected routes" says the other collection routes fetch their rows inside the route and have no lazy relationships in their response models. But several of them pass the same unconsumed ScalarResult as the three fixed here, and a few of those models do read a relationship (dag_display_name through AliasPath("dag_model", ...)). What keeps them off the loop is the route: joinedload, or building the items first, or a column-only model.

Maybe reword it as:

Several of the other list routes pass the same unconsumed ScalarResult, but nothing is
left to query while they serialize: the route either eager-loads with joinedload or
builds the items first, or the response model reads columns only.

You're right, sorry for the misleading, fixed.

[pierrejeambrun]

I just pushed a small adjustment commit, but looking good overall.

Thanks for the fix. 👍