[MM3-users] Re: Postorius claims 2 messages held when there are none - out of sync

26 Jun 2023

      --On Monday, June 26, 2023 8:24 AM -0700 Mark Sapiro <mark@msapiro.net>
wrote:
...
On 6/26/23 12:01 AM, Ken Alker wrote:
...
When I view a list via Postorius the "Held Messages" menu item has an
inverse-red-"2" next to it, as if there are two held messages.  There
are, in fact, no messages in "/opt/mailman/mm/var/queue/*" (assuming the
held messages should be in "pipeline" subdirectory).  When I click on
"Held Messages" I get "Something went wrong" followed by "HTTP Error
500: {"title": "500 Internal Server Error"}".  How do I fix this?
The held messages are not in any queue. They are stored in Mailman's
var/messages/ hierarchy. They can be examined with mailman qfile
Is the var/messages hierarchy also where all the archived emails are stored
for future viewing via the web interface?
...
Also, there is a long thread at
https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/threa
d/UWCUQYU7Q5X5LWNII57ZZ4DDXE4DEFX7/ and maybe others that might be
relevant.
I have never used the mailman shell before, but based on the referenced
thread I learned to do this (note that the thread also taught me how to
rewrite it to narrow down to just the list with issues so I didn't delete
held messages in other lists, if my case):
for verification:
venv) mailman@speedy:~/web/logs$ mailman shell -l
sbarc-list@lists.netlojix.com
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
The variable 'm' is the sbarc-list@lists.netlojix.com mailing list
...
...
...
requests = IListRequests(m)
first = True
for request in requests.held_requests:
...     key, data = requests.get_request(request.id)
...     if first:
...             first = False
...             print(m.list_id)
...     print (f"""

... Sender: {data['_mod_sender']}
... Subject: {data['_mod_subject']}
... Date: {data['_mod_hold_date']}
... Reason: {data['_mod_reason']}
... """)
...
and then to delete the two messages:
(venv) mailman@speedy:~/web/logs$ mailman shell -l
sbarc-list@lists.netlojix.com
Welcome to the GNU Mailman shell
Use commit() to commit changes.
Use abort() to discard changes since the last commit.
Exit with ctrl+D does an implicit commit() but exit() does not.
The variable 'm' is the sbarc-list@lists.netlojix.com mailing list
...
...
...
requests = IListRequests(m)
first = True
for request in requests.held_requests:
...     key, data = requests.get_request(request.id)
...     if first:
...             first = False
...             print(m.list_id)
...     print(f'request id: {request.id}, deleting')
...     requests.delete_request(request.id)
...
sbarc-list.lists.netlojix.com
request id: 27, deleting
request id: 28, deleting
The result of this, however, was that the web interface still claimed I had
two held messages.  I wasn't sure if there was some cron-type "sweeper"
process I had to wait to auto-run or if I had to manually do something to
create an update.  I then realized that the sample script had a ' >>>
commit ()" ' at the end, which I'd missed.  So, I re-entered the script
(but it didn't spit out that it deleted anything this time) and got an
error when I did the commit.  So, I figured the messages HAD been delete
and the commit wasn't really necessary.  When I went back to the web
interface, the number of held messages was at 0 and I no longer get the
original error when clicking on "Held messages", so my issue is solved.
But this does leave me with some educational questions:

Did I affect something somehow with my "commit", or was there a job that
cleaned things up (if so, what job)?

Is the "commit" even necessary (I saw it in someone else's script in the
thread)?

Is there a way to save a script and then execute it via shell rather
than typing it in every time (it appears from the examples that people are
typing them in every time, which is super tedious; I didn't paste for fear
of doing something damaging, but maybe that would work)?

Are the request.id's of the messages dynamic/changing, or are they fixed
for life?  I thought I'd delete based on exact request.id without looping
but I was afraid maybe they were changing over time and that this wouldn't
be a good idea.  Might be nice to know for the future.

Thanks for the guidance!
Ken