Skip to content

FAB Providers API get_application_builder cache miss trigger init_appbuilder #72937

Closed

Description

@adrian-edbert

Under which category would you file this issue?

Providers

Apache Airflow version

3.3.0.1

What happened and how to reproduce it?

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
  • Repeat API calls

Example

curl -v -X POST "http://127.0.0.1:8080/auth/token"      -H "Content-Type: application/json"      -d '{"username": "admin", "password": "admin"}'
{"access_token":"asdf"}

TOKEN='asdf'

curl -X GET "http://localhost:8080/auth/fab/v1/roles" -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json"

Are you willing to submit PR?

  • Yes I am willing to submit a PR!

Code of Conduct

Activity

  1. AbarnaaSree commented on Sep 12, 2026

    @AbarnaaSree

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions