Fix race condition in auth manager initialization

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.

[kimyoungi99]

Closes#61108

Problem

When sending concurrent requests to /auth/token, intermittent 500 errors occur:

AttributeError: 'AirflowAppBuilder' object has no attribute 'sm'

create_auth_manager() creates a new instance on every call without checking for an existing one. Under concurrent requests, one thread can overwrite _AuthManagerState.instance while another thread's instance is still being initialized via init(), resulting in an uninitialized auth manager being served.

Fix

Apply double-checked locking in create_auth_manager() so the auth manager is created exactly once:

defcreate_auth_manager() ->BaseAuthManager:
if_AuthManagerState.instanceisNone:
with_AuthManagerState._lock:
if_AuthManagerState.instanceisNone:
auth_manager_cls=get_auth_manager_cls()
_AuthManagerState.instance=auth_manager_cls()
return_AuthManagerState.instance

The first check avoids lock overhead on subsequent calls. The second check (inside the lock) prevents duplicate creation when multiple threads pass the first check simultaneously.

What's changed

• airflow-core/src/airflow/api_fastapi/app.py: Added threading.Lock to _AuthManagerState and guarded instance creation with double-checked locking
• airflow-core/tests/unit/api_fastapi/test_app.py: Added test_create_auth_manager_thread_safety — spawns 10 concurrent threads and verifies singleton behavior

Testing

• All 9 tests in test_app.py pass locally (including the new one)
• prek, ruff check, ruff format all clean

[vincbeck]

Cool!

[kimyoungi99]

Fixed the CI failure in test_upgradedb[auth1-2].

The initial singleton implementation cached the auth manager instance unconditionally, but upgradedb() switches between auth manager classes via config (e.g. SimpleAuthManager → FabAuthManager). The cached instance from a previous config was being returned instead of creating a new one for the updated config.

Added an isinstance check so the singleton is invalidated when the configured auth manager class changes. The thread-safety guarantee (double-checked locking) remains intact.

• test_upgradedb[auth0-1] ✅
• test_upgradedb[auth1-2] ✅ (was failing)
• test_create_auth_manager_thread_safety ✅

[jason810496]

Thanks for helping out, I just approved the CI.

Just FYI, we might need to update the provider tests if necessary for this version (I’m not sure yet). For the previous PR that tried to resolve the issue (#61310), we need to update the provider tests.

[kimyoungi99]

Looked into the CI failures — I think the provider DB tests (MySQL, Postgres, Sqlite) are failing because the singleton caching returns a stale FabAuthManager instance bound to a previous Flask app context (KeyError: 'AUTH_USER_REGISTRATION').

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

[jason810496]

I'm thinking rather than adding cleanup to individual test fixtures, it might make more sense to call purge_cached_app() directly in get_application_builder() since it creates a fresh Flask app each time. What do you think?

Thanks for updating the context.

I just approved the CI again, let's see whether current PR are able to pass all CI.
If current changes already able to pass the CI, I think we're good to go and there is no need to change other areas just to pass the unit test.

Additionally, the auth manager will initialized in FastAPI instead of Flask context

airflow/providers/fab/src/airflow/providers/fab/auth_manager/api_fastapi/routes/login.py

Lines 61 to 82 in 56a26f9

	@auth_router.get(
	"/logout",
	status_code=status.HTTP_307_TEMPORARY_REDIRECT,
	)
	deflogout(request: Request) ->RedirectResponse:
	"""Generate a new API token."""
	withget_application_builder():
	login_url=get_auth_manager().get_url_login()
	secure=request.base_url.scheme=="https"orbool(conf.get("api", "ssl_cert", fallback=""))
	response=RedirectResponse(login_url)
	response.delete_cookie(
	key="session",
	secure=secure,
	httponly=True,
	)
	response.delete_cookie(
	key=COOKIE_NAME_JWT_TOKEN,
	secure=secure,
	httponly=True,
	)
	returnresponse

Calling purge_cached_app to clear the auth manager instance for every API call might not be efficient IMHO.

[kimyoungi99]

Sorry for the extra CI round — my Breeze setup was slightly off so I thought the previous push would pass.
First-time contributor here, bear with me :)

The singleton's @cached_property on security_manager was causing AUTH_USER_REGISTRATION KeyErrors when multiple Flask apps are created in the same process (e.g., CLI commands calling get_application_builder() internally). Fixed by:

• Clearing the auth manager singleton in get_application_builder() before creating a new Flask app
• Adding purge_cached_app() to test fixtures that call application.create_app() with a different auth manager config

Verified locally using Breeze (--backend postgres --python 3.10).
All green.

[jason810496]

Thanks @kimyoungi99, LGTM!

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker 5c9171a v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

[jason810496]

I manually backported in #62326.

[pierrejeambrun]

@kimyoungi99 we will revert this PR because it's not ready to merge actually. It's causing some trouble. Do you mind re-opening a PR so we can keep improving and fixing before we merge it again?

[kimyoungi99]

@pierrejeambrun Thanks for catching this. I'll re-open a PR with the production code change in get_application_builder() removed.