[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
bundle exec rspec qa/specs/features/browser_ui/4_verify/ci_variable/pipeline_with_protected_variable_spec.rb
- 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.
-
I have evaluated the MR acceptance checklist for this MR.