Skip to content

Stop ReactiveCaching from needless Environment refreshes

David Wilkins requested to merge less-reactivecaching-for-environments into master

What does this MR do?

Stop ReactiveCaching from needless Environment refreshes

Screenshots

Currently, Environment has the following ReactiveCache setting:

  • reactive_cache_refresh_interval = 1.minute (Default Value)
  • reactive_cache_lifetime = 10.minutes (Default Value)

This causes ReactiveCacheWorker to run at least 10 times before the lifetime of the :active key expires.

When ReactiveCache receives a request for a currently :active request, the active request is expires time is reset to reactive_cache_lifetime from the current time - meaning that the redis keys will always stay active while they are being requested.

Changing the values to:

  • reactive_cache_refresh_interval = 1.minute
  • reactive_cache_lifetime = 55.seconds

will cause the lifetime of the :active key to expire sooner than the ReactiveCacheWorker runs only if the value key has not been requested in the interim. If the user has navigated away from the page, the ReactiveCacheWorker will NOT continue to refresh the data for 10 minutes. The next execution of the ReactiveCacheWorker will be the last one.

I left the refresh interval at 1.minute since our users probably expect to get refreshes on 1 minute intervals.

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

This is a tricky one to test - to empirically verify ...

  • Bring up two tabs - one on the GitLab projects page, and one on the /admin/sidekiq/scheduled?poll=true page
  • Select a project with environments
  • Navigate to Operations -> Environments
  • Notice a ReactiveCachingWorker for each environment scheduled for 1 minute into the future
  • With this MR
    • ReactiveCachingWorker will NOT continue to be scheduled if the page is not refreshed
    • If the page is refreshed after ReactiveCachingWorkers have completed, ReactiveCachingWorker will schedule itself again
    • If the page is refreshed before ReactiveCachingWorkers have completed, ReactiveCachingWorker will schedule itself again
  • Without this MR
    • ReactiveCachingWorker will reschedule itself at least 9 more times (assuming no more user interaction)
    • If the page is refreshed before ReactiveCachingWorkers have completed, the ReactiveCachingWorker scheduling will be extended for 10 more minutes
    • If the page is refreshed after ReactiveCachingWorkers have completed, the ReactiveCachingWorker will reschedule itself at least 9 more times.

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • [-] 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

Merge request reports