Fix AirflowSDKConfigParser missing mask_secrets method

[Subham-KRLX]

AirflowSDKConfigParser was missing the mask_secrets() method which caused an AttributeError on startup whenever settings.initialize() called conf.mask_secrets() (e.g. running airflow db migrate).

The method existed only on the core AirflowConfigParser and was never added to the SDK subclass. Added mask_secrets() to AirflowSDKConfigParser using SDK-native imports, matching the same logic as the core implementation.

closes: #66074

Was generative AI tooling used to co-author this PR?
Yes — Claude (For Pr description)

[stephen-bracken]

I think this needs to be added to the superclass in airflow.shared.configuration.parser.AirflowConfigParser?

[Subham-KRLX]

I think this needs to be added to the superclass in airflow.shared.configuration.parser.AirflowConfigParser?

The shared base has zero secrets masker imports by design it's a pure parsing library Core's AirflowConfigParser defines mask_secrets() at the core layer for the same reason each subclass owns its masking using its own secrets masker coupling the shared base to secrets masking would be the wrong direction.

[stephen-bracken]

one further point - the error from the issue occurs when importing airflow.configuration.conf from airflow.settings, which does implement the mask_secrets() method. I think we need to understand why the sub class isn't instantiated there

[Subham-KRLX]

one further point - the error from the issue occurs when importing airflow.configuration.conf from airflow.settings, which does implement the mask_secrets() method. I think we need to understand why the sub class isn't instantiated there

Good point settings.py does import conf from airflow.configuration which already has mask_secrets() so the real question is why AirflowSDKConfigParser ends up as conf in the reporter's setup my fix makes the SDK parser safe to call regardless but the root cause of why the wrong class is being used as conf is worth digging into further.

[stephen-bracken]

I found the cause, I was importing conf from airflow.providers.common.compat.sdk in my airflow_local_settings.py, which was defaulting to the sdk config parser

#66074 (comment)

[Subham-KRLX]

Thanks for tracking that down the compat provider intentionally routes conf to airflow.sdk.configuration on Airflow 3 so AirflowSDKConfigParser can legitimately end up as the active conf this fix ensures it works correctly in that scenario. Whether the compat routing should be revisited is a separate call for maintainers.