fix sdk configuration to use $AIRFLOW_CONFIG env

[wjddn279]

closed: #64918

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[Vamsi-klu]

This fixes the AIRFLOW_CONFIG case, but I think the fallback path still misses one edge case. If AIRFLOW_CONFIG is unset and AIRFLOW_HOME is something like $HOME/airflow or ~/airflow, get_airflow_config() still joins the raw value instead of the expanded path. Core expands AIRFLOW_HOME first, so it would be good to align the SDK behavior here and add a test for that fallback path too.

[Vamsi-klu]

The AIRFLOW_CONFIG support looks correct and matches core's implementation at airflow-core/src/airflow/configuration.py:555-560. Good fix.

I have a couple of observations though.

The PR adds expand_env_var around AIRFLOW_HOME in get_sdk_expansion_variables (line 102), but the fallback path in get_airflow_config still uses the raw os.environ.get("AIRFLOW_HOME", os.path.expanduser("~/airflow")) without expand_env_var. So if someone sets AIRFLOW_HOME to something like $CUSTOM_DIR/airflow (without shell expansion), config value expansion would see the expanded path but get_airflow_config would see the unexpanded one.

Core solves this by having a dedicated get_airflow_home() function (configuration.py:550-552) that calls expand_env_var once, and both get_airflow_config and get_all_expansion_variables use that. It might be cleaner to do the same thing here in the SDK rather than sprinkling expand_env_var in two places with slightly different behavior.

On tests, both test cases cover the path where AIRFLOW_CONFIG is set. It would be good to also have one for the default fallback when AIRFLOW_CONFIG is not set, something like asserting that get_airflow_config() returns {AIRFLOW_HOME}/airflow.cfg when the env var is absent. That way if someone accidentally breaks the fallback path it gets caught.

Also small thing, the PR body says "closed:" but GitHub auto-close needs the keyword "closes:" (e.g. closes: #64918).