jason810496 opened a new pull request, #68712: URL: https://github.com/apache/airflow/pull/68712
- related: https://github.com/apache/airflow/pull/68696#discussion_r3433102278 ## Why Pointed out in above comment, we should propagate the `logging_level` info from Supervisor (Task-SDK world) to Lang-SDK runtime to respect the Airflow side `conf`. So that no matter user configure the `[logging/logging_level]` setting using `airflow.cfg` or secret backend, the Lang-SDK should retrieve the same conf. ## How Here're the approach we came up with: 1. **(Current approach)** Passing as `AIRFLOW__LOGGING__LOGGING_LEVEL` env, each Lang-SDK will consume by `os.environ` themself. 2. Passing by CLI flag like `java -classpath ... --comms=... --logs=... --logging-level=...` CLI. Cons: We will introduce a new CLI flag for all the further `conf` propagation. (There isn't `--comms` or `--logs` equivalent Airflow env, so having the existing `--comms, --logs` as-is is a valid direction) 3. Passing by `StartUpDetails.logging_level`. Cons: Caught by @uranusjr that the Task subprocess had already started producing logs (e.g. logging for connecting to the coordinator) before the Task subprocess got the `StartUpDetails` msgpack, which causes the wrong logging level at the Task subprocess startup time. --- ##### Was generative AI tooling used to co-author this PR? - [x] Yes, with help of Claude Code (Opus 4.8) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) -- 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]
