-
Notifications
You must be signed in to change notification settings - Fork 703
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
Core: Fix crash when trying to log an exception #4313
base: main
Are you sure you want to change the base?
Conversation
In #3028, we added a new logging filter which checked `record.msg`. However, you can pass whatever you want into a logging call. In this case, what we missed was https://github.com/ArchipelagoMW/Archipelago/blob/ecc3094c70b3ee1f3e18d9299c03198564ec261a/MultiServer.py#L530C1-L530C37, where we pass an Exception object as the message. This currently causes a crash with the new filter. The logging module supports this. It has no typing and can handle passing objects as messages just fine. What you're supposed to use, as far as I understand it, is `record.getMessage()` instead of `record.msg`.
If this isn't just merged by a different core maintainer without peer review (prayge), then @kedNalatacId would like your peer review on this if you have a minute to look at it |
A similar line exists in customserver here: Archipelago/WebHostLib/customserver.py Line 303 in ecc3094
|
The PR that added this was merged two days ago |
looks good to me; sorry for missing this use case. |
Co-authored-by: Doug Hoskisson <[email protected]>
In #3028, we added a new logging filter which checked
record.msg
.However, you can pass whatever you want into a logging call. In this case, what we missed was https://github.com/ArchipelagoMW/Archipelago/blob/ecc3094c70b3ee1f3e18d9299c03198564ec261a/MultiServer.py#L530C1-L530C37, where we pass an Exception object as the message. This currently causes a crash with the new filter.
As far as I can tell, the logging module supports this. It has no typing and can handle passing objects as messages just fine, it just converts them to a string.
What you're supposed to use, as far as I understand it, is
record.getMessage()
instead ofrecord.msg
, which is guaranteed to be a string that represents what the final message will actually be.