Skip to content

Disable calls to Projects::VulnerabilityFeedbackController#index

Why are we doing this work

Projects::VulnerabilityFeedbackController#index is the main culprit for the SLI degradation of Category:Vulnerability Management.

This controller will be affected by two pieces of WIP:

  1. Deprecate and remove Vulnerabilities::Feedback
  2. MR Security widget refactor, v2

I am reluctant to propose performance work on this controller before the WIP above is complete, because it would be throw-away work (the v2 MR widget doesn't use the vulnerability_feedback endpoint at all).

We do have MR Security widget performance improvements prioritized right after them.

Until then, we can:

  1. limit the number of entries in the MR widget
  2. deteriorate the UI by reducing calls to vulnerability_feedback (or disabling the endpoint response)

This issue is around implementing a solution for the second point above.

https://gitlab.slack.com/archives/CV09DAXEW/p1673473256676779 (internal link; expires 2023-04-12)

the #index method is used to decide whether findings in the MR widget will be struck-out (i.e. their status is “dismissed”). So we could change the method to always return empty, which means the entry wouldn’t be formatted and users would need to click on it to see its status.

There’s a #count method that also does the same query, but we didn’t investigate where it’s used. Depending where it’s needed, we would decide whether to leave it working or disable it as well.

An alternative to disabling the endpoint in the backend, is to stop calling it from the frontend. This is left to be decided as part of refinement.

Either way, the change should be behind a feature flag, enabled by default (i.e. the endpoint is called/responds with content) so in specific environments we can disable it (i.e. the endpoint is not called/empty response).

Relevant links

Non-functional requirements

  • Documentation:
  • Feature flag:
  • Performance:
  • Testing:

Implementation plan

  • backend create a new feature flags which will be used to control Projects::VulnerabilityFeedbackController#index response.
  • backend Update #index so it returns [] based on the FF.

Although the backend approach seems simpler, frontend related code could also provide an alternative approach. The above method is called multiple times from grouped_security_reports_app.

As discussed in this thread, #count hasn't been used thus shouldn't have any impact on the either bandwidth or performance. There is no instance in Kibana as far as it is recorded.

Verification steps

Edited by Zamir Martins