This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vinay.sajip
Recipients avdd, cheryl.sabella, danishprakash, vinay.sajip, xtreak
Date 2018-09-24.17:04:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1537808696.45.0.956365154283.issue34334@psf.upfronthosting.co.za>
In-reply-to
Content
Having looked at it again, Adrian Dries might be right that setting exc_text to None will also do the trick, and perhaps in a better way. The reasoning:

Handler.format() formats record.msg % record.args, and caches it in record.message. If there is exception information, it will format that and cache it in record.exc_text, then append the exception text to the message and return that.

So prepare() calling

msg = self.format(record)

will return the complete message and exception text in msg, and record will have record.message = record.msg % record.args, and record.exc_info and record.exc_text will have exception info.

When preparing, the prepare() method pretends that the already-formatted message was logged - record.msg % record.args is equivalent to record.message with no args, so it does

record.msg = msg (contains formatted message + exception info)
record.args = None (since the args have already been used)
record.exc_info = None (since the exception info has already been used)

but I forgot that record.exc_text should also be zapped, as it should always reflect the contents of record.exc_info. So I think that setting record.exc_text to None is perhaps the correct thing to do here, as Adrian originally suggested.

There should be a test that specifically exercises this with a QueueHandler and QueueListener - test_queue_listener needs to test for this case in case a regression reappears.

The reason for converting record.msg, record.args, record.exc_info and record.exc_text to record.msg = fully formatted message, None, None and None is that the arguments and exception trace may not be pickleable, which is a consideration when using multiprocessing queues. Otherwise we could just have passed them over unchanged.

Are you OK with changing the PR in line with the above, Cheryl?
History
Date User Action Args
2018-09-24 17:04:56vinay.sajipsetrecipients: + vinay.sajip, avdd, cheryl.sabella, xtreak, danishprakash
2018-09-24 17:04:56vinay.sajipsetmessageid: <1537808696.45.0.956365154283.issue34334@psf.upfronthosting.co.za>
2018-09-24 17:04:56vinay.sajiplinkissue34334 messages
2018-09-24 17:04:56vinay.sajipcreate