-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Paw/ct 1652 restore default logging #6447
Conversation
Verified locally the same behavior documented in the issue, and also verified that the propose fix restores the expected behavior:
|
@MichelleArk You deleted your comment while I was responding, but yes, there is at least the danger that a logger could be double-added. This was my comment: Our implementation of setup_event_logger() clears the loggers and handlers for this reason, before adding the configured loggers. My feeling is that anyone else who accesses EVENT_MANAGER directly is taking their life in their hands and should know what they are doing. We also hope to get rid of all globals associated with logging, and several other inelegant hacks in this file, in version 1.5. Hopefully we can discuss that further at Brown Bag. |
EVENT_MANAGER: EventManager = EventManager() | ||
EVENT_MANAGER.add_logger( | ||
_get_logbook_log_config() if flags.ENABLE_LEGACY_LOGGER else _get_stdout_config() | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[answered here] Is there a risk of double-adding loggers downstream, leading to extraneous calls to logger.write?
resolves #6434
Description
Restore logging to stdout before the logging subsystem is fully configured, so that earlier errors are still presented to the user in some form.
Checklist
changie new
to create a changelog entry