Recover the revoked-token check from a stale DB connection (fixes idle-timeout 500)

[uplsh580]

Recover the JWT revoked-token check from a stale pooled DB connection so the first authenticated request after an idle period no longer returns HTTP 500.

Issue: #71395

Problem

With MySQL as the metadata DB and the FAB auth manager, the first authenticated request after the api-server sits idle longer than MySQL's wait_timeout fails with HTTP 500. The exception is an OperationalError (MySQL error 4031, "The client was disconnected by the server because of inactivity") raised from RevokedToken.is_revoked inside BaseAuthManager.get_user_from_token. The immediately following request succeeds, because the failed query resets the pooled connection — so in production it looks like intermittent 500s after overnight idle periods.

Root cause

1. The FAB auth manager shares core's scoped settings.Session. A prior request (e.g. FabAuthManager.deserialize_user, or FAB's Flask views) can leave that scoped session bound to a connection the database later drops on idle timeout. Because the connection is never returned to the pool, there is no checkout event — pool_pre_ping / pool_recycle cannot help.
2. This exact failure mode was reported in apache-airflow-providers-fab 3.4.0: Intermittent OperationalError (4031) when FAB session reuses a MySQL connection dropped due to idle timeout #62903 and fixed by fix(fab): recover from first idle MySQL disconnect in token auth #62919, which added a discard-and-retry recovery to FabAuthManager.deserialize_user.
3. But 3.2.0 introduced the JWT revocation check (AIP-84 : Add JWT token revokation for logout invalidation (#47952) #61339 / AIP-84): RevokedToken.is_revoked in get_user_from_token now runs before deserialize_user, so it is the first thing to touch the poisoned scoped session — and it had no recovery logic. The 500 that fix(fab): recover from first idle MySQL disconnect in token auth #62919 fixed is back, just raised one step earlier in the auth path.

Fix

Give the revoked-token check the same recovery deserialize_user already has: on SQLAlchemyError, discard the scoped session (settings.Session.remove()) and retry the check once on a fresh connection. The recovery is factored into a small BaseAuthManager._is_token_revoked helper so get_user_from_token stays readable.

This is the per-call-site variant proposed in the issue (the one that has been running in production for several weeks and eliminated these 500s). It is minimal and mirrors the established #62919 pattern rather than introducing a new session-management abstraction. A persistent DB error still surfaces — only a single transient stale-connection error is absorbed.

Tests

Added two regression tests in test_base_auth_manager.py. Both raise a 4031-style OperationalError on the first is_revoked call and assert the scoped session is discarded (settings.Session.remove()) and the check is retried exactly once:

• retry returns not revoked → the request is served transparently;
• retry returns revoked → InvalidTokenError("Token has been revoked") is still raised.

related: #71395

---

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

• Yes (please specify the tool below)

Generated-by: Claude Code following the guidelines