On 2/27/26 13:23, Phil Steel-Wilson via Mailman-users wrote:
I'm working at a volunteer organization with around a dozen mailing lists that were previously on mm2 that have been upgraded to mm3 with the upgrade to debian trixie. Mailman is running and the lists all work ok but i found 1800 mails in the shunt queue. Hyperkitty also shows all the old archives pre 2020 the same as in the django console. When i tried to unshunt the mails they moved to the bad queue. How do i find whats wrong here?
If this is the Debian package, you should be working with Debian. See <https://wiki.list.org/x/12812344>.
Mailman Core Version GNU Mailman 3.3.10 (Tom Sawyer) Mailman Core API Version 3.1 Mailman Core Python Version 3.13.5 (main, Jun 25 2025, 18:55:22) [GCC 14.2.0]
There is a compatibility issue between Mailman 3.3.10 from PyPI and Python 3.13, but this is apparently fixed in the Debian package. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...> and near the end of <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...>
Mails are shunted because of some uncaught exception in processing. See <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/...> for more info on dealing with shunted messages.
Messages can end up in the bad queue in multiple ways. One way is content filtering ends up with an empty message and the list's content filtering Filter Action is Preserve. This requires
filtered_messages_are_preservable: yes
in the [mailman] section of mailman.cfg.
The only other way messages end up in the bad queue is in reprocessing messages. When a message is picked up for processing by a queue runner it's extension is changed from .pck to .bak. Then if that runner crashes for some reason without finishing processing of that message, the .bak file remains and when the runner restarts, the entry is reprocessed. If unpickling the .bak throws an exception or if reprocessing the same message is tried 3 times without success, the message is placed in the bad queue.
The following errors have nothing to do with messages in the shunt or bad queues. They are the result of trying to log in to the web UI with the fedora oAuth login method which is apparently misconfigured.
Traceback (most recent call last): ... TypeError: OpenIDProvider.get_server_settings() missing 1 required positional argument: 'endpoint' ERROR 2026-02-27 20:50:19,995 1769748 django.request Internal Server Error: /mailman3/accounts/fedora/login/ Traceback (most recent call last): ... TypeError: OpenIDProvider.get_server_settings() missing 1 required positional argument: 'endpoint' ... ERROR 2026-02-27 20:51:20,841 1769748 django.request Internal Server Error: /mailman3/accounts/fedora/login/
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan