takayoshi-makabe commented on issue #70968:
URL: https://github.com/apache/airflow/issues/70968#issuecomment-5163307961
`dag_processor_log_target` was originally added in 2.4.0 (#25754) as a
genuine exclusive switch: the `airflow.processor` logger's Python logging
handler was swapped between a file handler and a stdout handler, so setting it
to `stdout` meant no file was ever created.
When the Dag File Processor was rewritten onto the Task SDK's
subprocess/structlog architecture (around 3.0/3.1), that handler-swap mechanism
was dropped entirely, and the config option silently stopped doing anything.
#65528 (merged 2026-04-20) reconnected the option, but wired it into the
`subprocess_logs_to_stdout` flag that already existed for **task** logs. That
flag is intentionally additive for task logs — it duplicates output to stdout
while always keeping the file, which makes sense there because task logs are
served via the Log API and can be uploaded to remote storage, so the file is
load-bearing.
Dag processor logs have neither of those dependencies (no API/UI route
serves them, and they're never uploaded to remote storage), so there's no
structural reason to force a file write when `dag_processor_log_target =
stdout`. The current behavior (always write the file, optionally also duplicate
to stdout) matches what #65528 intended for containers, but doesn't restore the
original exclusive semantics that the config's own docs still describe ("Where
to send dag parser logs. If 'file', logs are sent to log files...").
---
Drafted-by: Claude Code (Sonnet 5); reviewed by @takayoshi-makabe before
posting
--
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]
