migration check fails when on "helm install" without airflow.providers.fab.auth_manager.models.db.FABDBManager

[till]

Official Helm Chart version

1.19.0 (latest released)

Apache Airflow version

3.1.7

Kubernetes Version

not relevant

Helm Chart configuration

executor: KubernetesExecutor
securityContexts:
  pod:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

# FAB auth manager requires explicit external_db_managers so that
# `airflow db migrate` creates FAB tables (ab_user, ab_role, etc.).
# Auto-discovery via create_auth_manager() fails silently in the migrate job context.
config:
  database:
    external_db_managers: airflow.providers.fab.auth_manager.models.db.FABDBManager

# Global volume — mounts into all pods (including those running git-sync)
volumes:
  - name: github-app-key
    secret:
      secretName: airflow-github-app
      defaultMode: 0444

dags:
  gitSync:
    enabled: true
    repo: https://github.com/org/repo.git
    branch: main
    ref: main
    subPath: ""
    period: 60s
    securityContexts:
      container:
        allowPrivilegeEscalation: false
        capabilities:
          drop:
            - ALL
    extraVolumeMounts:
      - name: github-app-key
        mountPath: /etc/github-app
        readOnly: true
    env:
      - name: GITSYNC_GITHUB_APP_APPLICATION_ID
        valueFrom:
          secretKeyRef:
            name: airflow-github-app
            key: app-id
      - name: GITSYNC_GITHUB_APP_INSTALLATION_ID
        valueFrom:
          secretKeyRef:
            name: airflow-github-app
            key: installation-id
      - name: GITSYNC_GITHUB_APP_PRIVATE_KEY_FILE
        value: /etc/github-app/private-key.pem

postgresql:
  enabled: false
redis:
  enabled: false
flower:
  enabled: false
statsd:
  enabled: false
data:
  metadataConnection:
    protocol: postgresql
    # host, port, user, pass, db injected at deploy time
    sslmode: require

# Webserver secret key — injected via --set at deploy time
# webserverSecretKey: <set at deploy time>

# API Server serves the web UI in Airflow 3.x
apiServer:
  replicas: 1
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: "1"
      memory: 2Gi

scheduler:
  replicas: 1
  resources:
    requests:
      cpu: 250m
      memory: 512Mi
    limits:
      cpu: "1"
      memory: 2Gi

ingress:
  apiServer:
    enabled: true
    ingressClassName: haproxy
    hosts:
      - name: airflow.example.org
        tls:
          enabled: true

createUserJob:
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi

migrateDatabaseJob:
  resources:
    requests:
      cpu: 100m
      memory: 256Mi
    limits:
      cpu: 500m
      memory: 512Mi

Docker Image customizations

No response

What happened

Trying to setup Airflow, I was surprised I had to set the following:

config:
  database:
    external_db_managers: airflow.providers.fab.auth_manager.models.db.FABDBManager

Otherwise, services never start because the migration check fails.

What you think should happen instead

Maybe better defaults in the helm values. I am also not sure what "FAB" is really for. :)

How to reproduce

Take my config above:

helm upgrade --install -f values-from-helm.yml -f my-helm-values.yml etc.

Anything else

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[Subham-KRLX]

This PR fixes an issue where RunDBManager would silently skip FABDBManager discovery when the auth manager failed to initialize (common in migration-only environments) The fix ensures graceful handling of such cases.

[laurenhall1526-netizen]

This PR addresses an issue where RunDBManager would silently skip FABDBManager discovery if the auth manager failed to initialize—a scenario common in migration-only environments. The change ensures that such cases are handled gracefully, allowing migrations to proceed without unexpected skips or errors.

…

On Tue, Mar 24, 2026, 2:39 AM Subham ***@***.***> wrote: *Subham-KRLX* left a comment (apache/airflow#63847) <#63847 (comment)> This PR fixes an issue where RunDBManager would silently skip FABDBManager discovery when the auth manager failed to initialize (common in migration-only environments) The fix ensures graceful handling of such cases. — Reply to this email directly, view it on GitHub <#63847?email_source=notifications&email_token=B7IHA46OVPJ7K3ZFOK3AKV34SI3S3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJRGYYDIOBTGQ2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4116048344>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7IHA44NK6JOTB5YXRLPU7T4SI3S3AVCNFSM6AAAAACWVFUNPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCMJWGA2DQMZUGQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[till]

@vincbeck is this released in 3.1.8?

[vincbeck]

3.1.8 is already released so no. I'll create the backport to include it in 3.1.9, it will also be released in 3.2

[vincbeck]

This will be hard to backport. It depends on a new feature added in 3.2 but not backported (rightfully so) in 3.1.X. I think it is best to not backport it, especially because 3.2 is really close to be released

[till]

Makes sense, thank you for explaining it.