Hyperkitty list overview error: thread matching query does not exist
When attempting to visit the hyperkitty archives list overview for one of my two lists:
Https://lists.mydomain.com/hyperkitty/list/mylist@mydomain.com/
The area where the threads should appear shows the loading spinner (but the activity summary bar chart and most active posters post counts do eventually load).
The following appears in /var/log/mailman3/web/mailman-web.log:
ERROR 2022-05-23 17:50:50,201 1694 django.request Internal Server Error: /hyperkitty/list/mylist@mydomain.com/posted-to Traceback (most recent call last): File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python3/dist-packages/hyperkitty/lib/view_helpers.py", line 135, in inner return func(request, *args, **kwargs) File "/usr/lib/python3/dist-packages/hyperkitty/views/mlist.py", line 251, in overview_posted_to for thread in mlist.recent_threads: File "/usr/lib/python3/dist-packages/hyperkitty/models/mailinglist.py", line 142, in recent_threads return self.cached_values"recent_threads" File "/usr/lib/python3/dist-packages/hyperkitty/models/common.py", line 59, in __call__ return self.get_or_set(*args, **kwargs) File "/usr/lib/python3/dist-packages/hyperkitty/models/mailinglist.py", line 281, in get_or_set return [Thread.objects.get(pk=pk) for pk in thread_ids] File "/usr/lib/python3/dist-packages/hyperkitty/models/mailinglist.py", line 281, in <listcomp> return [Thread.objects.get(pk=pk) for pk in thread_ids] File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line 82, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 406, in get raise self.model.DoesNotExist( hyperkitty.models.thread.Thread.DoesNotExist: Thread matching query does not exist.
Viewing “All Threads” or Threads by month (any month) work as expected, displaying the appropriate threads.
The archives for this list worked previously. There was an incident that resulted in DNS not working and the archiver failing for a few days. The mail that came in during that time does show up in the other views.
The hyper kitty archives for a second list on this Mailman3 instance is working correctly.
How can I fix this view of the archives? Or how can I get more information on what might be failing?
Thanks,
Darren
On 5/23/22 11:11, Darren Hart via Mailman-users wrote:
When attempting to visit the hyperkitty archives list overview for one of my two lists:
Https://lists.mydomain.com/hyperkitty/list/mylist@mydomain.com/
The area where the threads should appear shows the loading spinner (but the activity summary bar chart and most active posters post counts do eventually load).
The following appears in /var/log/mailman3/web/mailman-web.log:
ERROR 2022-05-23 17:50:50,201 1694 django.request Internal Server Error: /hyperkitty/list/mylist@mydomain.com/posted-to Traceback (most recent call last): ... File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 406, in get raise self.model.DoesNotExist( hyperkitty.models.thread.Thread.DoesNotExist: Thread matching query does not exist.
Viewing “All Threads” or Threads by month (any month) work as expected, displaying the appropriate threads.
The archives for this list worked previously. There was an incident that resulted in DNS not working and the archiver failing for a few days. The mail that came in during that time does show up in the other views.
The hyper kitty archives for a second list on this Mailman3 instance is working correctly.
How can I fix this view of the archives? Or how can I get more information on what might be failing?
I'm not sure if this will help, but try running your django management
command with arguments runjob recent_threads_cache. Note that this
will be run daily if you are running the Cron Jobs for Mailman Web. See
https://docs.mailman3.org/en/latest/install/virtualenv.html?highlight=period...
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Wed, May 25, 2022 at 08:10:39AM -0700, Mark Sapiro wrote:
On 5/23/22 11:11, Darren Hart via Mailman-users wrote:
When attempting to visit the hyperkitty archives list overview for one of my two lists:
Https://lists.mydomain.com/hyperkitty/list/mylist@mydomain.com/
The area where the threads should appear shows the loading spinner (but the activity summary bar chart and most active posters post counts do eventually load).
The following appears in /var/log/mailman3/web/mailman-web.log:
ERROR 2022-05-23 17:50:50,201 1694 django.request Internal Server Error: /hyperkitty/list/mylist@mydomain.com/posted-to Traceback (most recent call last): ... File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 406, in get raise self.model.DoesNotExist( hyperkitty.models.thread.Thread.DoesNotExist: Thread matching query does not exist.
Viewing “All Threads” or Threads by month (any month) work as expected, displaying the appropriate threads.
The archives for this list worked previously. There was an incident that resulted in DNS not working and the archiver failing for a few days. The mail that came in during that time does show up in the other views.
The hyper kitty archives for a second list on this Mailman3 instance is working correctly.
How can I fix this view of the archives? Or how can I get more information on what might be failing?
I'm not sure if this will help, but try running your django management command with arguments
runjob recent_threads_cache. Note that this will be run daily if you are running the Cron Jobs for Mailman Web. See https://docs.mailman3.org/en/latest/install/virtualenv.html?highlight=period...
Thank you Mark. These are in cron, but I ran this (and all the runjobs hourly,daily, etc. options), checking after each. The failure persisted until I restarted mailman3-web, and then it started working again. I'm not sure what combination of cron jobs and restarting resolved the issue, but it's running again. Thanks again.
-- Darren Hart Ampere Computing / OS and Kernel
I had the exact same problem and running "mailman-web runjob recent_threads_cache" as user mailman in the virtual environment fixed the problem. I didn't think to stop and start the mailmanweb service, but what I did still seemed to work (hopefully I didn't mess something up in the process).
Tthere is now an implication that my daily recent_threads_cache job must not have been running, true? Is there some way to check to see if the jobs are running? I did a "crontab -l" and the cron jobs that appear are identical to what was suggested at https://docs.mailman3.org/en/latest/install/virtualenv.html?highlight=period....
On 6/28/23 10:17 PM, Ken Alker wrote:
Tthere is now an implication that my daily recent_threads_cache job must not have been running, true? Is there some way to check to see if the jobs are running? I did a "crontab -l" and the cron jobs that appear are identical to what was suggested at https://docs.mailman3.org/en/latest/install/virtualenv.html?highlight=period....
grep 'CRON.*runjobs' /var/log/syslog
will tell you if cron is running the various runjobs commands.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
On 6/28/23 10:17 PM, Ken Alker wrote:
Tthere is now an implication that my daily recent_threads_cache job must not have been running, true? Is there some way to check to see if the jobs are running? I did a "crontab -l" and the cron jobs that appear are identical to what was suggested at https://docs.mailman3.org/en/latest/install/virtualenv.html?highlight=period.... grep 'CRON.*runjobs' /var/log/syslog
will tell you if cron is running the various runjobs commands.
It is running every morning. Is it at all possible that running it manually did something that running it from CRON would not? I'm not sure why this solved the problem when the CRON job has been running every day.
On 6/29/23 8:05 AM, Ken Alker wrote:
It is running every morning. Is it at all possible that running it manually did something that running it from CRON would not?
It shouldn't make a difference.
I'm not sure why this solved the problem when the CRON job has been running every day.
Nor am I. It could be a coincidence, i.e., the issue could have resolved for some other reason.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Darren Hart -
Ken Alker -
Mark Sapiro