Skip to content

Reschedule Feedback -> StateTransition background migration

Michał Zającrequested to merge
387665-reschedule-migratevulnerabilitiesfeedbacktovulnerabilitiesstatetransition-background into master

What does this MR do and why?

This MR:

  1. Reschedules the background migration
  2. Skips permission check when migrating Vulnerabilities::Feedback records

Related to #387665 (closed)

Why was the migration halted?

This background migration leverages application code which created subtransactions. We have removed subtransactions in !108592 (merged).

We made the original scheduling post-deployment migration a no-op so our self-hosted customers are not affected.

We also removed the previously scheduled jobs in !107731 (merged).

Now it should be safe to reschedule the background migration

Why do we skip permission check?

During testing, @ahegyi ran into Gitlab::Access::AccessDeniedError but we couldn't reproduce it in the testing pipeline afterwards after several attempts. Later, Jihu team reported that it happened in their instance.

This can occur in two cases:

  1. Subscription for the given user expires at the time the background migration is ran
  2. The user no longer has necessary permissions for the given project

As this is a data migration we need to be able to create appropriate records for consistency, as such I've opted to skip the permission check if the skip_permission_check parameter is set to true (it's false by default). As far as I'm concerned there's no way to pass that parameter from the web UI or our API.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Merge request reports