Skip to content

Expire CurrentSettings when checking job status

Reuben Pereira requested to merge 32351-fix-caching-bug into master

What does this MR do?

The status_create_self_monitoring_project and status_delete_self_monitoring_project APIs check the status of create & delete Sidekiq jobs respectively by checking if the self-monitoring project has been created/deleted (as well as by checking if the job has completed). The ID of the self-monitoring project is stored in the application_settings table.

The create Sidekiq job saves the project ID into the application_settings table and the delete job deletes it. Since the change to the application_settings table happens in a Sidekiq job, Gitlab::CurrentSettings in the controller might still contain the old instance_administration_project_id.

Therefore, this MR:

  1. Calls Gitlab::CurrentSettings.expire_current_application_settings before checking the value of Gitlab::CurrentSettings.instance_administration_project_id.

  2. This MR also moves the .in_progress? check above the check for Gitlab::CurrentSettings.instance_administration_project_id, so that we only expire the cache once the job has completed.

Issue: #197968 (closed)

Screenshots

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

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
Edited by 🤖 GitLab Bot 🤖

Merge request reports

Loading