Andrushika opened a new pull request, #76415: URL: https://github.com/apache/airflow/pull/76415
## Why Most write routes in the public API run `log_action` first, to write an audit row. `log_action` is an `async def`, so its two lookups and its commit ran on the event loop thread. When the connection pool has no free connection, the loop waits there for one. The requests that hold the connections need the loop to finish, so the API server stops until `pool_timeout`. On 3.4.0rc2 with `airflow standalone` and Postgres, I sent 600 `POST /api/v2/assets/events`, 24 at a time. They took 136 s, and ten of them failed with a 500 after 60 s. 3.3.2 took 4.9 s for the same requests. 3.3.2 also commits on the event loop there, and I did not find which change between 3.4.0b2 and 3.4.0rc1 exposes the stall. ## What The two lookups and the commit now run in the threadpool, like the JWT revocation check after #74856. With this change on the rc2 image, the same requests took 9 s with no errors. The new tests use the `event_loop_queries` fixture from #74247. This keeps the sync session. #67799 tracks the move to async sessions. The access checks for backfills and event logs, and for pools, connections and variables in multi-team mode, still query on the event loop. I left them for a follow-up to keep this change small. related: #74239 --- ##### 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]
