Skip to content

Use specialized worker to refresh authorizations on project transfer

What does this MR do?

This change implements #223852 (closed)

Feature flag rollout issue is: #334237 (closed)

Advantage

From Kibana, these endpoints enqueued over 50,000 AuthorizedProjectsWorker jobs in the last 7 days. (This number can vary up or down easily based on traffic, number of project members, number of members in the old namespace and new namespace etc)

Screen_Shot_2021-06-22_at_11.44.33_AM

The fact is that this endpoint can enqueue N different AuthorizedProjectsWorker jobs whenever a project is transferred from one namespace to another.

With the new approach introduced in this MR, instead of N jobs, there will be just 1 AuthorizedProjectUpdate::ProjectRecalculateWorker enqueued when a project is transferred.

However, till we are satisfied with the correctness of AuthorizedProjectUpdate::ProjectRecalculateWorker, we are still gonna run the old re-calculation approach as a safety-net with a 1 hour delay. We will be comparing the correctness of both approaches using Kibana after the change is deployed, just like we did here.

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

Does this MR contain changes to processing or storing of credentials or tokens, authorization and authentication methods or other items described in the security review guidelines? If not, then delete this Security section.

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team
Edited by Manoj M J

Merge request reports