mozilla
[Bug]: Cannot delete a scanner query rule that has many results
What happened?
When you delete a scanner query rule, there is an deletion confirmation page that lists all linked scanner query results on the confirmation page. If a rule has has many results (tens of thousands or more) the page load takes a long time, longer than the request timeout limit. As a user you see the rested timed out error page, without being able to confirm deletion of the scanner query rule.
What did you expect to happen?
There should be a way to delete a scanner query rule that has a lot of results.
Is there an existing issue for this?
- [X] I have searched the existing issues
┆Issue is synchronized with this Jira Task
To clarify, the server throws a 502 error after some time:
Error: Server Error
The server encountered a temporary error and could not complete your request.
Please try again in 30 seconds.
This is because the default Django deletion confirmation view tries to show all objects and there are too many. We should probably add a generic workaround to our admin (possibly all admin tools using django admin) to not try to do that if there are too many objects.
And even outside the confirmation Django will try to cascade...
Or we could just soft-delete the query rules and hide them forever...
We could but I don't see a use case for that which means all it does is bloating the size of the db.
Can we just hide the related instances from the confirmation page (assuming that would address the performance issue)? That information is not helpful anyway, as it is just a link to a ScannerQueryResult instance, and certainly nobody is going to click any at that stage, especially if it's hundreds, thousands or more.
We can - that's what I'm suggesting above before my second comment, but Django would still load them all to try to cascade, so we'd have to work around that too.
If we want to try to just customize the related instances shown on the confirmation page, that's doable via https://docs.djangoproject.com/en/4.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.get_deleted_objects. As I said I'm not sure it'd be enough because we'd still need to do the cascade delete in python when the deletion is confirmed, but it's worth a try...
Playing with this locally, overriding get_delete_object() does seem to work. Once displaying the related results is bypassed, the deletion is actually fairly straightforward, only the 2 DELETE queries are left, and they only depend on the pk of ScannerQueryRule being deleted.
I had a yara rule with 8272 (5539 add-ons) on stage, or on dev with 11567 (8608 add-ons) - deleted both without errors.
I don't have a query rule with the number of results from prod to reproduce perhaps.
