You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Durabletask logger is not respecting root_logger #102
The durabletask package creates its own logger using logging.Logger() directly (not logging.getLogger()), which means it creates an independent logger that doesn't respect the root logger configuration.
Ideally, the package should be using logging.getLogger() since that enables all customers/clients to easily disable or modify the verbosity of the durabletask-* packages as they need.
This was deliberate, but before my time, let's keep this issue around essentially as a feature request as there are definite benefits to using logger.getLogger() instead
A direct swap from logging.Logger(...) to logging.getLogger(...) would be unsafe even if we retain the current default handler: the managed logger would inherit the root effective level, and its fixed name would make it shared across every client/worker instance. Repeated construction would accumulate default or caller-provided handlers, leading to duplicate records and possible handler leakage between instances.
This draft instead adds an optional logger parameter to the core and Azure Managed clients/workers. A supplied logger is used unchanged: the SDK does not alter its handlers, formatter, level, filters, or propagation. log_handler and log_formatter remain supported for compatibility but now emit a DeprecationWarning; they are mutually exclusive with logger and are planned for removal in a future major version.
This gives customers the standard logging integration they need today, including root/logger hierarchy configuration and structured logging, without changing the existing default-output or per-instance handler behavior for current applications.
Activity
andystaples commentedon Jan 9, 2026
This was deliberate, but before my time, let's keep this issue around essentially as a feature request as there are definite benefits to using logger.getLogger() instead
andystaples commentedon Aug 10, 2026
Implemented the additive migration path in #252.
A direct swap from logging.Logger(...) to logging.getLogger(...) would be unsafe even if we retain the current default handler: the managed logger would inherit the root effective level, and its fixed name would make it shared across every client/worker instance. Repeated construction would accumulate default or caller-provided handlers, leading to duplicate records and possible handler leakage between instances.
This draft instead adds an optional logger parameter to the core and Azure Managed clients/workers. A supplied logger is used unchanged: the SDK does not alter its handlers, formatter, level, filters, or propagation. log_handler and log_formatter remain supported for compatibility but now emit a DeprecationWarning; they are mutually exclusive with logger and are planned for removal in a future major version.
This gives customers the standard logging integration they need today, including root/logger hierarchy configuration and structured logging, without changing the existing default-output or per-instance handler behavior for current applications.