OctoPrint
[Request] Some kind of "octoprint bisect" to help determining problematic third party plugins
Is your feature request related to a problem? Please describe.
We often see people experiencing issues with some of their installed third party plugins. It is fairly easy to figure out an issue is third party plugin related thanks to safe mode. Pin pointing the exact plugin causing the problem however is an excruciatingly slow process, having manually disable and enable a ton of plugins.
Describe the solution you'd like
A binary search approach similar to how git bisect works could help pin point the offending plugin faster. The use could start the debugging process. OctoPrint disables half of the plugins and restarts. The user is then instructed to test for the existance of the issue. If it still reproduces, OctoPrint disables half of the currently enabled issues. If not, OctoPrint re-enables half of the formerly disabled half of plugins. Repeat until the plugin has been clearly identified. The binary search approach will keep the number of required research at a minimum.
A challenge here will be the UI to do this. It would probably be good to be able to run through the steps both from the UI, the recovery mode and the CLI, in order to be able to apply this debugging approach even if OctoPrint's web interface itself is rendered inaccessible by the misbehaving plugin.
Describe alternatives you've considered
Continue like now and frustrate users with 50 third party plugins.
Additional context
No response
I don't dislike the idea, my argument is more one of time spent elsewhere.
Usually when there's something wrong with an OctoPrint install, it is with a certain part, maybe the communication, the UI, etc. Usually (many) users can take a guess at which plugins might be the problem, and if the users can't do it then someone on the forums etc. might suggest a likely candidate for a problem. It's rare that you have to fly into a problem like this completely blind and have to do complete binary search - instead, disable the few most likely problem causers and get to the problem quicker. A naïve binary search will get you to the problem faster than one-by-one, but I don't know how common it is to need to go that far.
I can see this being (relatively) a lot of work to implement, so I wanted to make sure it would actually be useful in a number of situations, rather than more pressing issues and bigger ideas with a wider impact.
I agree that this is definitely not high prio due to the complexity vs corner case situation. I think it would definitely help a ton with debugging however, and maybe even reduce the support overhead slightly.
I was actually hoping that by putting it here someone might feel inclined to give it a shot ;)