amoghrajesh commented on PR #60074: URL: https://github.com/apache/airflow/pull/60074#issuecomment-3709021417
> I think for now (cc @amoghrajesh @kaxil @ashb) - the only good way is to make sure those defaults are also loaded by shared configuration. The issue is that those defauilts are coming from providers and you need to load provider's configuration before the defaults can be used, so this is an equivalent of pre-fetching defaults "just in case" before provider configuration is loaded. > > So option 3: > > > (Longer term) Extend SDK conf to also include provider fallback defaults > > in its lookup chain > > I do not think "minimak changes" is a decision factor. Correctness is more important. > > The root cause is the same as described in [#60087 (comment)](https://github.com/apache/airflow/pull/60087#issuecomment-3708410863) -> we currently completely do not control the sequence in which different parts of airflow are initialized, this depends pretty much on the way how we import things -> in this case the problem is that we first retrieve the default values, before provider manager is initialized and defaults are retrieved. > > I think eventually, it will be fixed when we switch to explicit initialization of internal airflow shared functionalities The decision to not load provider configurations in shared library was kind of deliberate to keep the shared library agnostic of providers, but I guess we can have the sdk conf load the providers conf with an aim to stop providers relying on airflow-core and consuming from airflow task sdk instead? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
