Skip to content

Nullify `dismissal_reason` when a vulnerability is un-dismissed

Michael Becker requested to merge 437004-resetting-a-vulnerability-from-dismissed-to-detected-does-not-reset-dismissal-feedback-in into master

What does this MR do and why?

When a vulnerability is dismissed, we save the dismissal_reason to the vulnerability_reads table in the dismissal service

When we want to un-dismiss a vulnerability, we use the revert_to_detected_service.rb to reset a vulnerability from dismissed to detected

However, we do not also wipe away the dismissal_reason that was written to the vulnerability_reads table from the dismissal_service.

Because of this, we will be left with a situation where vulnerability.dismissed? will return false, while at the same time vulnerability.vulnerability_read.dismissal_reason will still return a populated dismissal_reason

When we reset a vulnerability to detected, we should nullify the dismissal_reason field in the associated vulnerability_read

Raw SQL

UPDATE
    "vulnerability_reads"
SET
    "dismissal_reason" = NULL
WHERE
    "vulnerability_reads"."vulnerability_id" = 733

explain query

To simulate un-dismissing a vulnerability, I went to the vulnerability dashboard and selected a dismissed vulnerability to use as the id in the explain query

https://postgres.ai/console/gitlab/gitlab-production-main/sessions/25298/commands/80345

Time: 39.168 ms  
  - planning: 3.307 ms  
  - execution: 35.861 ms  
    - I/O read: 34.231 ms  
    - I/O write: 0.000 ms  
  
Shared buffers:  
  - hits: 26 (~208.00 KiB) from the buffer pool  
  - reads: 11 (~88.00 KiB) from the OS file cache, including disk I/O  
  - dirtied: 2 (~16.00 KiB)  
  - writes: 0

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Related to #437004
Resolves #437815 (closed)

Edited by Michael Becker

Merge request reports