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

ProcessorFormatter doesn't handle librarys which send dicts to standard logger well #187

wrouesnel opened this Issue Nov 23, 2018 · 1 comment


None yet
2 participants
Copy link

wrouesnel commented Nov 23, 2018

The processor formatter uses this line to distinguish between Structlog and regular messages:

if isinstance(record.msg, dict):

Unfortunately this runs afoul of any library or bug which happens to accidentally pass a dict object to the Python standard library logger (in the wild I've found the connexion library does this in some of its initialization code, producing exceptions when using structlog). This happens because the record entry doesn't have _logger attached because it didn't come through structlog.

IMO the ideal solution would be for the wrap_for_formatter handler to actually supply a wrapped dictionary type which could be tested for directly, but this doesn't seem particularly viable.

The best solution therefore is probably to embrace duck-typing in this code path and change the check to ensure the expected attributes are actually there:

if isinstance(record.msg, dict) and hasattr(record, "_logger") and hasattr(record,"_name"):

wrouesnel added a commit to wrouesnel/structlog that referenced this issue Nov 23, 2018

wrouesnel added a commit to wrouesnel/structlog that referenced this issue Nov 23, 2018

Check a dict passed to ProcessorFormatter actually came from structlog.
ProcessorFormatter assumes certain attributes are attached by wrap_for_formatter
but originally only tested if it was receiving a dictionary as the log message.

This breaks if any libraries you use happen to pass dictionaries as log messages
expecting them to print using default string formatting.

Fortunately since the behavior of the LogRecord is different between the two
paths, we can resolve this by testing for the relevent attrs before choosing.

Fixes hynek#187.

This comment has been minimized.

Copy link

hynek commented Feb 2, 2019

Fixed by #189

@hynek hynek closed this Feb 2, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment