Eason09053360 opened a new pull request, #73422:
URL: https://github.com/apache/airflow/pull/73422
## Why
`BaseAuthManager.get_user_from_token` runs on the event loop for every
authenticated
request, and the revocation lookup it performs is a synchronous DB round
trip — UI
polling, worker heartbeats and `airflowctl` all queue behind it. That same
lookup
piggybacks cleanup of expired rows as one unbounded `DELETE` on the request
path,
holding row locks for the whole transaction. The connection-pool symptom was
reported
in #66493, which its reporter closed alongside #66494 (later closed as
stale).
## What
- `base_auth_manager.py`: the lookup moves to `run_in_threadpool`, matching
`TeamAuthorizationMiddleware.dispatch`.
- `revoked_token.py`: cleanup deletes at most 100 rows per pass and resumes
on the
next request while batches fill; a non-blocking lock keeps the
now-concurrent
passes to one at a time, and a failed pass rolls back so the revocation
read after
it survives on PostgreSQL.
- `deserialize_user` still does DB I/O on the loop for FAB — it needs FAB's
unlocked
`TTLCache` made thread-safe first, so it is left for a follow-up.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes (please specify the tool below)
Generated-by: Claude Code (Opus 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]
