ted
September 6, 2024, 8:56am
9
This is most likely happening because there exists a problem check tracker but the problem check logic is no longer there. The most likely way this would happen would be installing a plugin with a problem check and then uninstalling it. The tracker would then still be there, but the checking logic is missing.
I have a fix for this here:
discourse:main ← discourse:dev/clear-trackers-for-uninstalled-checks
opened 07:52AM - 06 Sep 24 UTC
### What is this change?
When running checks, we look to the existing problem… check trackers and try to grab their `ProblemCheck` classes.
In some cases this is no longer in the problem check repository, e.g. when the check was part of a plugin that has been uninstalled.
In the case where the check was scheduled, this would lead to an error in one of the jobs.
### How does this fix it?
This fix has two parts:
1. If a problem check tracker can't find it's `ProblemCheck` class, it destroys itself and any admin notices associated with it. It then returns `nil`.
2. The job that selects which checks to run now accounts for the fact that the `ProblemCheck` class could be `nil`, and filters it out of the run.
Bonus:
- Scheduled checks now honour the `enabled = false` configuration, same as realtime checks.
2 Likes