Skip to content

Do inline project authorizations refresh only when there is a single element

Manoj M J requested to merge mmj-auth-refresh-inline into master

What does this MR do and why?

This is the continuation to the effort in !90495 (merged), by which we are trying to move away from running project authorizations refresh jobs in an inline, waiting manner - ie, we do not want these refresh jobs wait on the request on Puma. We want to reach a state where all refresh jobs are executed purely in Sidekiq, with no waiting on the request.

!90495 (merged) was the first step towards this, and with that the current state is:

  • jobs with 1 to 3 arguments - processed inline, along with the request.
  • jobs with 4 to 100 arguments - processed via Sidekiq, and does not wait. (this behaviour is behind th async_only_project_authorizations_refresh feature flag, which is now 100% enabled on production)
  • jobs with greater than 100 arguments - processed via Sidekiq and does not wait.

With this MR, we are going a step further, and making this:

  • jobs with 1 argument - processed inline, along with the request.
  • jobs with 2 to 3 arguments - processed via Sidekiq, and does not wait. (this behaviour is behind the inline_project_authorizations_refresh_only_for_single_element feature flag.)
  • jobs with 4 to 100 arguments - same as existing behaviour, as described above. (ie, processed via Sidekiq, and does not wait.)
  • jobs with greater than 100 arguments - same as existing behaviour, as described above. (ie, processed via Sidekiq, and does not wait.)

Screenshots or screen recordings

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

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

Edited by Manoj M J

Merge request reports