There should be a CLI command, and maybe eventually a UI, to repeatedly toggle half the remaining extensions and ask the user whether a problem is there. This would massively reduce the time needed to find problematic extensions on communities with more than a few extensions, which is probably the vast majority of Flarum communities.
The "search space" for bisect binary search could just be the dependency-resolved order.
At each iteration, after setting the proper subset of extensions to be enabled/disabled, we should:
- Recompile/republish assets
- Clear cache
- Maybe something else
Before starting this process, we should write the currently enabled extensions to a file, so that the forum can recover if the bisect is aborted. This file (e.g. bisect_state.json
) could then be extended to power a web UI version of bisect, although we'd want to keep the CLI one around too.
If a community has 10 extensions, finding the culprit would take 3-4 steps
If it has 30, finding the culprit would take 4-5 steps.
At 100, it would be 6-7, and at 300, it would still only take 9 steps. Yay base-2 log!
A slightly more sophisticated version could take one (or several) extensions that MUST be kept enabled and should not be considered in the binary search; this could be used to find which problematic extension is causing issues when interacting with a working extension.