Fix '/auth/token' 500 when FAB auth manager is recreated#65710
Merged
Conversation
Prevent FAB auth manager recreation from breaking /auth/token When FAB auth manager is initialized for the FastAPI app, the auth manager instance stores the Flask app used by the FAB-backed auth routes. Later, init_appbuilder() recreates the global auth manager instance. That replacement loses the initialized flask_app reference, so /auth/token fails with: "Flask app is not initialized. Check that FabAuthManager started up correctly." Reuse the already initialized auth manager when present and only fall back to create_auth_manager() if initialization has not happened yet.
|
Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide
|
vincbeck
approved these changes
Apr 23, 2026
Contributor
|
CI is failing |
Only reuse initialized FAB auth managers in init_appbuilder The previous change reused the global auth manager whenever one was already initialized. That was too broad for test environments, where the global auth manager may exist but not be a FabAuthManager. This updates the logic to reuse the existing auth manager only when it is already FAB-backed, and to fall back to reate_auth_manager() otherwise. This preserves the /auth/token fix while avoiding FAB CLI and auth manager test failures caused by reusing a non-FAB auth manager.
Remove trailing whitespace from the blank line after the local FabAuthManager import in AppBuilder initialization. The import remains visually separated from the executable setup code, while matching the format expected by pre-commit hooks so CI does not fail with hook-made changes.
Contributor
Author
|
@vincbeck CI is now passing after the latest updates. Could you please take another look when you have a chance? |
vincbeck
reviewed
Apr 24, 2026
Replace the generic auth-manager lookup in init_appbuilder with get_fab_auth_manager(), which already guarantees a FabAuthManager instance or raises when the configured manager is not FAB-based.
add import get_fab_auth_manager
|
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
79 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix '/auth/token' 500 when FAB auth manager is recreated
'init_auth_manager()' initializes the global auth manager and
'FabAuthManager.get_fastapi_app()' stores the Flask app used by the
FAB-backed auth routes on that instance.
Later, 'init_appbuilder()' calls 'create_auth_manager()' again. That
replaces the initialized global auth manager with a fresh instance that
does not have 'flask_app' set, causing '/auth/token' to fail with:
'Flask app is not initialized. Check that FabAuthManager started up correctly.'
This change reuses the already initialized auth manager when available
and only falls back to 'create_auth_manager()' if initialization has
not happened yet.
This was reproduced on Airflow 3.1.2 deployments using
'FabAuthManager', where:
Validation
Manually reproduced before the patch:
Manually validated after the patch:
Was generative AI tooling used to co-author this PR?