Remove invalid project ID logic from project filter in order to make it easier to understand and debug
On the group-level and security center vulnerability report, there is a project filter:
Please watch these 2 videos, which explains the issue better than text can:
When there is a querystring parameter for the project filter (i.e. vulnerabilities/?projectId=43&projectId=42
), there is currently some logic that will check if each project ID is valid by doing a GraphQL request, and if an ID is invalid, it will be removed as a filter for the vulnerability list. This was to get around an issue where when there is only one project ID in the querystring but it's invalid, the vulnerability list will return no results but it won't be obvious why.
While the current implementation solves this edge case, it also makes it hard to understand what's going on, both in the code and when debugging. Extra GraphQL requests are made if there are invalid IDs, and the code that handles this behavior is spread across multiple places. This makes it hard to figure out what's initiating all the GraphQL requests, and why. It's also difficult to write specs to cover it as well because it involves multiple back-to-back requests to the same endpoint, just with different data, and our testing tools don't really handle this use case well.
In short, we have to balance maintainability of the code with the feature, and this is a case where having simpler, easier to understand code outweighs the benefit of the feature. Thus, this MR is to remove the "transparently handle invalid project IDs" logic, and replace it with something else.
Implementation plan
-
Remove code that handles the invalid project ID use case -
Add a way to show the user when there are invalid project IDs in the querystring