Metadata secret required for workers #74850

Activity

1. devgonvarun

   added

   kind:bugThis is a clearly a bugThis is a clearly a bug

   needs-triagelabel for new issues that we didn't triage yetlabel for new issues that we didn't triage yet

   on Oct 16, 2026
2. anzinmhd commented on Oct 16, 2026

   

   anzinmhd

   on Oct 16, 2026

   Contributor

   More actions

   I reproduced this with Airflow 3.2.2, KubernetesExecutor, and multiNamespaceMode: true on a local Kubernetes cluster.

   The scheduler, API server, Dag processor, and database ran in one namespace. A single-task Dag used a pod override to launch its worker in a separate namespace. I provided the worker's required ConfigMaps, service account, and other template-referenced Secrets, but left the metadata Secret absent.

   Observed results:

   • Without the metadata Secret in the worker namespace, the Airflow worker container remained in CreateContainerConfigError. Kubernetes reported secret "repro322-metadata" not found.
   • After adding that Secret with a correctly formatted PostgreSQL URI containing deliberately invalid credentials, a fresh Dag run completed successfully. The worker reported exit_code=0 and final_state=success and used the Execution API.

   The apparent cause is the shared Helm environment helper. The worker pod template includes standard_airflow_environment, which adds both AIRFLOW__DATABASE__SQL_ALCHEMY_CONN and AIRFLOW_CONN_AIRFLOW_DB as mandatory metadata Secret references. Kubernetes must resolve these references before starting the container, even though this Airflow 3 task does not need valid metadata database credentials.

   I also compared the local worker template, helper, and default values used for this reproduction with upstream main at b9aa889577; all three files are identical. This was a runtime test of Airflow 3.2.2, not an execution test of Airflow built from main.

   I’m preparing a focused chart fix with regression tests and will open a PR shortly.