Over the years using Open edX, I think I used Django Debug Toolbar (DJDT) maybe once or twice to actually help me debug something, but I’ve cursed it many times due to bugs it has caused, which range from obvious crashes to very subtle bugs where it has taken me hours to realize that there’s nothing wrong with the code - it’s just some interference from DJDT causing transaction failures or incorrect query counts or some other problem.
I find it much more harmful than useful so I’ve always tried to turn it off on my devstacks, but it’s not actually easy to turn off, and inevitably I’ll eventually re-create a devstack and not realize that it’s on until it bites me again.
Anyhow, now that we are mostly using MFEs, you can’t even access DJDT from most of our platform -but it’s still randomly breaking APIs for your convenience. I’d like to propose that we remove it completely. (If that’s considered a breaking change, then I’d like to propose that we disable it by default for all devstacks, and DEPR it for eventual removal. But it’s already never enabled in production so is not part of our production API.)
On the one hand I completely agree with this, but on the other, we still render course content in edx-platform and that’s where this tooling would come in handy to debug perf issues in particular. Though I wonder if turning it on when needed rather than having it on by default would be better. And also we have a lot of plugins right now and I’m not sure how many of them we really need enabled anymore.
I’m curious to hear from others but unless there is opposition, I would be willing to experiment with turning it off by default and seeing who is missing it or when it was needed again to debug something that couldn’t be figured out some other way.
I absolutely use it, but rarely, and I’m fine making it a developer option that you can enable or disable in a test setting. I have used it to performance tune some django admins that are brutally slow with large datasets, and once I used it to debug some extremely broken filters.
so I’m fine making it off-by-default, as long as we clearly document how to reenable it.
FWIW, I use Django Debug Toolbar all the time. I debug API endpoints with it by using the history features to load a previous recent request into the debug panel. I especially use it to debug database query issues, though occasionally other things as well (like verifying what signals are emitted in a view, how often the cache is hit, getting a sense for how much CPU time was spent to double-check whether certain in-process caching is working as expected, etc.). Yeah, it can be finicky and annoying sometimes, but I find it really useful.
To be clear, I’m okay with making it optional, and even off by default. But I wanted to voice that I absolutely do use it on a regular basis.