Fix stdlib errors being logged as exceptions sometimes. #92
Conversation
stdlib error log records were sometimes logged with exception level, sometimes logged with error level by structlog. This is due to the non 1-1 mapping between log levels and log names (some levels have the same name). If the developer adds a new log name that conflicts with an already existing log level without blacklisting it, it produces the unexpected behavior. It's even random in Python 3: because of the hash seed, it will always produce the same result in the same python interpreter instance, but will vary according to the interpreter instance. The problem is that once the mistake is done, it's pretty complicated to debug. And it's even more complicated to write a test (since you will never notice a behavior change in the same python instance). I think it would be a good idea to add a disclaimer message at least. Feel free to add a test for this to prevent future errors and time loss if you have any idea on how to write it.
Current coverage is 100% (diff: 100%)@@ master #92 diff @@
===================================
Files 13 13
Lines 739 753 +14
Methods 0 0
Messages 0 0
Branches 91 94 +3
===================================
+ Hits 739 753 +14
Misses 0 0
Partials 0 0
|
Just to be 100% clear. With the previous implementation,
(expected)
(unexpected) This means that the You'll probably notice tat this PR does not contain any tt's not about lazyness, but this one is incredibely hard to write. The best test I could write would be a test that:
I don't write this kind of Schrödinger test, it's pointless… If you have any better idea on how to implement it, let me know. |
Sorry I didn’t get around to look at this earlier. It looks important and should have a changelog entry I think. |
@hynek Done. |
thank you and sorry i didn’t get around to this earlier! |
stdlib error log records were sometimes logged with exception level, sometimes
logged with error level by structlog. This is due to the non 1-1 mapping
between log levels and log names (some levels have the same name). If the
developer adds a new log name that conflicts with an already existing log
level without blacklisting it, it produces the unexpected behavior. It's even
random in Python 3: because of the hash seed, it will always produce the same
result in the same python interpreter instance, but will vary according to the
interpreter instance.
The problem is that once the mistake is done, it's pretty complicated to debug.
And it's even more complicated to write a test (since you will never notice a
behavior change in the same python instance). I think it would be a good idea
to add a disclaimer message at least. Feel free to add a test for this to
prevent future errors and time loss if you have any idea on how to write it.