You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
FAB Providers API get_application_builder cache miss trigger init_appbuilder #72937
I have a script to sync some of our internal roles into FAB API, this will calls roles and users api multiple times to sync into Airflow FAB
During one of such script run, I noticed that calling FAB roles or users API multiple times (in around 1000 times over 2 hours) will eventually lead to create memory issue, k8s pod seems to increase memory usage into more than 50 GBs and this leads to degradation of API server and causing either OOM killed or slow response time (up to 10s) eventually lead to liveness probe failure
Each API call seems to run providers/fab/src/airflow/providers/fab/auth_manager/cli_commands/utils.py get_application_builder function this will:
Create a new Flask app
yield cached return_app_builder
When cache is missed, it will call init_appbuilder and I think Python store the cache in memory
Since the cache is always missing it will eventually causing memory issue
What you think should happen instead?
Calling API should not call init_appbuilder every single time, so either API calls need to store the created flask app object in memory or just remove cache entirely if it's expected to init every time
Operating System
Debian GNU/Linux 12 (bookworm)
Deployment
Official Apache Airflow Helm Chart
Apache Airflow Provider(s)
fab
Versions of Apache Airflow Providers
3.7.0
Official Helm Chart version
1.18.0
Kubernetes Version
1.33.5
Helm Chart configuration
Not Applicable
Docker Image customizations
Not Applicable
Anything else?
Occur every time
One way to replicate
Using helm chart with admin user and default user admin enabled
Go inside the pod and authenticate with the admin user (using username and password) through auth/token endpoint
Use the token generated from the login method
Call get auth/fab/v1/roles
Check logs to see that it triggers initialize_app_builder with logs Initializing AppBuilder and Registering Route
Hi @adrian-edbert, I’d like to investigate and work on this issue.
The repeated get_application_builder() calls triggering init_appbuilder() and potentially retaining application-related objects in memory looks like an important issue, especially given the reported memory growth under repeated API requests.
I’d like to first trace the current caching and application-builder lifecycle in the FAB provider and add a regression test that reproduces the repeated initialization behavior. Based on that, I can work on the smallest fix that avoids unnecessary initialization while preserving the existing behavior.
If this approach sounds reasonable, I’d be happy to submit a PR.
Activity
AbarnaaSree commentedon Sep 12, 2026
Hi @adrian-edbert, I’d like to investigate and work on this issue.
The repeated
get_application_builder()calls triggeringinit_appbuilder()and potentially retaining application-related objects in memory looks like an important issue, especially given the reported memory growth under repeated API requests.I’d like to first trace the current caching and application-builder lifecycle in the FAB provider and add a regression test that reproduces the repeated initialization behavior. Based on that, I can work on the smallest fix that avoids unnecessary initialization while preserving the existing behavior.
If this approach sounds reasonable, I’d be happy to submit a PR.