Skip to content

[E2E] Harden cancel pipeline when user blocked spec

What does this MR do and why?

[E2E] Harden cancel pipeline when user blocked spec

In some situations the async nature of how users are added to a project can mean that the permissions haven't been applied prior to a request being made in our test. We should add a retry to allow for this situation to avoid flaky test failures in these situations, which appear to manifest in the form of 403 errors.

Fixes #417661 (closed)

How to set up and validate locally

  1. bundle exec rspec qa/specs/features/browser_ui/4_verify/ci_variable/pipeline_with_protected_variable_spec.rb
  2. In order to verify that this works when the async job is slow, I found it useful to apply some logic to simulate a sleep in sidekiq. This allowed for recreating the error as described in #417661 (closed) and #435608 (closed) repeatedly, and with this fix applied, the test now gracefully handles this situation.
Suggested diff
diff --git a/config/initializers/sidekiq.rb b/config/initializers/sidekiq.rb
index 8df12671f265..39cdea7e73f7 100644
--- a/config/initializers/sidekiq.rb
+++ b/config/initializers/sidekiq.rb
@@ -1,4 +1,5 @@
 # frozen_string_literal: true
+
 module SidekiqLogArguments
   def self.enabled?
     Gitlab::Utils.to_boolean(ENV['SIDEKIQ_LOG_ARGUMENTS'], default: true)
@@ -32,7 +33,17 @@ def enable_semi_reliable_fetch_mode?
 
 enable_json_logs = Gitlab.config.sidekiq.log_format != 'text'
 
+class DelayedProcessingMiddleware
+  def call(_worker, _job, _queue)
+    sleep(5)
+    yield
+  end
+end
+
 Sidekiq.configure_server do |config|
+  config.server_middleware do |chain|
+    chain.add DelayedProcessingMiddleware
+  end
   config[:strict] = false
   config[:queues] = Gitlab::SidekiqConfig.expand_queues(config[:queues])
 

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