Thanks for your advice, Stephen.
As I've removed the file from the shunt queue I don't believe that file is causing the 500 error any more.
I've confirmed the error is not cached in the browser.
If the issue does not reside in the shunt queue (no other files indicate parse errors when checking via command line) are there any other places I should look for data that is addressed by that page?
Cheers, Simon.
From: Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> Sent: Monday, 31 August 2020 23:51 To: Simon Handfield <simon.handfield@sl.nsw.gov.au> Cc: mailman-users@mailman3.org <mailman-users@mailman3.org> Subject: [MM3-users] Re: Mailman3 throws 500 error (unicode encode) when loading held messages in Postorius
Simon Handfield via Mailman-users writes:
I have been able to identify a file in the shunt queue that threw a matching error when I performed mailman qfile on it.
I have run a loop over all remaining files in the shunt queue and all the remaining files can be accessed by mailman qfile without error.
Good. But there are still a bunch of problems with those files since they got shunted.
I moved this file out of the queue in the hope that I would then be able to load the held_messages page successfully. Unfortunately I am still seeing a 500 error on loading the page.
If this is a Mailman problem, I don't understand it. The shunt queue is not the moderation queue. The shunt queue is for messages that Mailman cannot handle without throwing an exception. Once a message is sent to the shunt queue, Mailman ignores it, so it shouldn't cause problems for the moderation page.
Have you tried restarting Mailman since moving the qfile?
If that doesn't work, and if it's the same error message and traceback, the easy suspect is browser caching (although we should be disabling that, I hope). Try a manual refresh (usually Ctrl-R or in the menu). If that doesn't work, try a private browsing window or another browser if you don't want to clear the cache or restart the browser.
I temporarily reenabled debug logging to confirm that the same error was being thrown.
Assuming that file was the cause are there other steps I need to perform in addition to removing the file from the shunt queue directory?
The only one I can think of is the check for browser-side caching.
Unfortunately, Mark's out of town (like, on top of a mountain with no bars on his phone), and I am not going to be able to do much with this until Thursday at the earliest. If you do get a new traceback, post it here (somebody else may have an idea).
If you like you may send me the qfile at the address in From. I'll see if I can reproduce the bug, and I'm pretty sure I can tell you what's in the file so at least you'll know whether it's important to somebody who isn't a scammer/spammer.
Steve
_
[State Library of NSW]<https://www.sl.nsw.gov.au/> Simon Handfield Desktop and Infrastructure Leader simon.handfield@sl.nsw.gov.au<mailto:simon.handfield@sl.nsw.gov.au> +61 2 9273 1535
Macquarie Street, Sydney NSW 2000, Australia www.sl.nsw.gov.au<https://www.sl.nsw.gov.au/>
This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of their organisation.