On 06/16/18 19:46 PM, Mark Sapiro wrote:
On 06/16/2018 06:38 PM, Eric Abrahamsen wrote:
A bump for this, I've been getting this series of errors once a minute for weeks now. There must be some way to clear out dangling thread references? And I take it that for the meantime we shouldn't be using the "delete thread" feature of hyperkitty...
[Q] ERROR Failed [rebuild_thread_cache_votes] - Thread matching query does not exist. [Q] INFO Process-1:1 processing [rebuild_email_cache_votes] [Q] ERROR Failed [rebuild_email_cache_votes] - Email matching query does not exist. [Q] INFO Process-1:2 processing [rebuild_thread_cache_votes] [Q] ERROR Failed [rebuild_thread_cache_votes] - Thread matching query does not exist. [Q] INFO Process-1:3 processing [rebuild_email_cache_votes] [Q] ERROR Failed [rebuild_email_cache_votes] - Email matching query does not exist. [Q] INFO Process-1:4 processing [rebuild_thread_cache_votes] [Q] ERROR Failed [rebuild_thread_cache_votes] - Thread matching query does not exist.
Is there something more I should be doing to sync hyperkitty's database with mailman? I've got the crontab file in place, and that appears to be running without error. Anything else?
Except that 'django-admin runjobs minutely' is probably what's producing the errors.
Yes, I guess that was poorly phrased...
You might try 'django-admin runjob empty_threads' (normally a monthly job) or 'django-admin runjob thread_order_depth' (normally a yearly job). I don't know if they will clear this up or not, but I don't think it would hurt to try.
See 'django-admin runjob --list' to see the various jobs and note that 'django-admin runjob update_index' which runs minutely and does an incremental update is not the same as 'django-admin update_index' which only runs manually and does a full search index update.
I've tried all the above with no luck, and am getting ready to dive a bit deeper. It's been a bit confusing tracking all the code flows. The rebuild_thread_cache_votes error occurs once a minute, at second 21. The rebuild_email_cache_votes error is also once a minute, but at second 56.
Am I right that the only job that runs once a minute is the "runjob update_index" command, and that the error must be (eventually) arising from there? Does it seem meaningful that the two errors are offset by around 30 seconds? Lastly, searching the source for the rebuild_(email|thread)_cache_votes functions, they only seem to be called within the "on_vote_added" method of Email and Thread objects, but I don't see how that can be the source of the errors (as the objects in question obviously exist). So it must be update_index, which means I should be looking in haystack (ha) for whatever eventually calls these functions. Does that all sound correct?
Thanks for your pointers, Eric