### Summary Merge requests with MRAP can be blocked with `EVALUATION_SKIPPED` on pipelines where every scan ran, succeeded and was ingested. The customer sees "could not be evaluated within the specified timeframe" from the policy bot, which then resolves without intervention some time after all evaluations complete. The cause appears to be a conflict between two independent timers. `UnblockPendingMergeRequestViolationsWorker` fires 90 seconds after pipeline completion and skips any violation still in `running`. The only worker that can move a `scan_finding` violation out of `running` is `SyncMergeRequestApprovalsWorker`, which carries `concurrency_limit -> { 200 }`. The deadline does not account for that throttle, so whenever queue deferral exceeds 90 seconds the merge request is blocked before evaluation has been allowed to start. Deferral is driven by instance-wide load on the worker class. ### Steps to reproduce The condition depends on fleet-wide queue pressure and does not reproduce reliably on demand. I've found some traces to use as examples on GitLab.com to expose this happening for customers. Example below in Relevant Logs section. ### Example project Observed on GitLab.com in production Sidekiq logs. Pipeline and project identifiers held internally; see the linked support ticket. ### What is the current _bug_ behavior? Policy evaluation for a merge request is deferred by a concurrency throttle that the evaluation deadline does not account for. When deferral exceeds the deadline, the merge request is blocked with `EVALUATION_SKIPPED` and required approvals are reinstated, despite the evaluation itself being both correct and fast when it eventually runs. The customer-facing message is: > Policy `%{policy}` could not be evaluated within the specified timeframe and, as a result, approvals are required for the policy. Ensure that scanners are present in the latest pipeline. That guidance is misleading in this case. Scanners were present, ran to success, and were ingested. There is no action available to the customer that would prevent recurrence. The comment accompanying `UNBLOCK_PENDING_VIOLATIONS_TIMEOUT` at `ee/app/workers/security/unenforceable_policy_rules_pipeline_notification_worker.rb:15` justifies the 90 second value against the 99.99th percentile of policy worker _duration_. Duration is not the quantity that defeats the deadline. In the case recorded below, evaluation duration was 2.597 seconds and queue **deferral** was 138.602 seconds. ### What is the expected _correct_ behavior? The merge request should remain in a checking state until evaluation has actually run. Where the evaluating worker is deferred by queue pressure, the customer should see the security policy check still in progress (perhaps a notification indicating it is delayed), then a settled verdict once it completes. A deferral of two minutes should mean two minutes of waiting, not a block instated, especially one that self resolves after customer gets an email about it, comes to investigate and wastes time finding that there is nothing for them to fix except wait for the evaluation to be ready to complete, or discover that the evaluation _has_ completed and the bot has revised its comment. ### Relevant logs Production Sidekiq logs for a single affected pipeline, 2026-09-01, times in UTC. Interleaved from `pubsub-sidekiq-inf-gprd*` and presented in chronological order. ``` `2026-09-01T13:15:27.022 Security::Scans::IngestReportsWorker JID-7c876482e14fd4e0674ab10c: start 2026-09-01T13:15:28.931 Security::Scans::IngestReportsWorker JID-7c876482e14fd4e0674ab10c: done: 1.909331 sec 2026-09-01T13:15:29.993 Security::Scans::IngestReportsWorker JID-6227bd85d606267aeafea959: start 2026-09-01T13:15:30.021 Security::Scans::IngestReportsWorker JID-9195c347f756fefb8383e35c: start 2026-09-01T13:15:30.358 Security::Scans::IngestReportsWorker JID-9195c347f756fefb8383e35c: done: 0.337793 sec 2026-09-01T13:15:31.670 Security::Scans::IngestReportsWorker JID-6227bd85d606267aeafea959: done: 1.677018 sec 2026-09-01T13:15:39.298 Security::StoreScansWorker JID-a2ab1da1c4579c4fed5515ae: start 2026-09-01T13:15:41.213 Security::StoreScansWorker JID-a2ab1da1c4579c4fed5515ae: done: 1.915173 sec 2026-09-01T13:15:41.935 Security::ScanResultPolicies::SyncFindingsToApprovalRulesWorker JID-47ecf8c84cdb4f9c6bd27178: start 2026-09-01T13:15:42.741 Security::ScanResultPolicies::SyncFindingsToApprovalRulesWorker JID-47ecf8c84cdb4f9c6bd27178: done: 0.805664 sec 2026-09-01T13:19:12.197 Security::UnenforceablePolicyRulesPipelineNotificationWorker JID-a560a14e796049d93f428f7e: start 2026-09-01T13:19:12.695 Security::ScanResultPolicies::SyncFindingsToApprovalRulesWorker JID-5d3f79613d54648566b572d8: start 2026-09-01T13:19:13.296 Security::ScanResultPolicies::SyncMergeRequestApprovalsWorker JID-98610987e469e1e30b9baa95: concurrency_limit: paused 2026-09-01T13:19:13.421 Security::ScanResultPolicies::SyncFindingsToApprovalRulesWorker JID-5d3f79613d54648566b572d8: done: 0.725419 sec 2026-09-01T13:20:42.735 Security::ScanResultPolicies::UnblockPendingMergeRequestViolationsWorker JID-46f9f2ef45029a9eecbd13a2: start 2026-09-01T13:20:49.243 Policy evaluation timed out, skipping and requiring approvals 2026-09-01T13:20:49.254 Security::ScanResultPolicies::UnblockPendingMergeRequestViolationsWorker JID-46f9f2ef45029a9eecbd13a2: done: 6.519364 sec 2026-09-01T13:21:31.898 Security::ScanResultPolicies::SyncMergeRequestApprovalsWorker JID-98610987e469e1e30b9baa95: start 2026-09-01T13:21:34.495 Security::ScanResultPolicies::SyncMergeRequestApprovalsWorker JID-98610987e469e1e30b9baa95: done: 2.597436 sec ` ``` The pipeline completed at 13:19:12.197, arming the 90 second policy evaluation deadline held by `UnblockPendingMergeRequestViolationsWorker`. `SyncFindingsToApprovalRulesWorker` ran 498ms later and enqueued `SyncMergeRequestApprovalsWorker`, which which calls `UpdateApprovalsService` the path by which a `scan_finding` rule reaches a terminal violation status. That job was immediately paused by its `concurrency_limit` at 13:19:13.296, 1.1 seconds into a 90 second budget, and remained throttled for 138.602 seconds. The deadline fired at 13:20:42.735 with the violation still in `running`, producing `EVALUATION_SKIPPED` and reinstating required approvals. The evaluation itself then ran at 13:21:31.898 and finished in 2.597 seconds, 49.163 seconds after the merge had already been blocked. ### Impact Any project on GitLab.com enforcing a merge request approval policy with `scan_finding` rules is exposed whenever aggregate load on `SyncMergeRequestApprovalsWorker` pushes deferral past 90 seconds. The block is customer-visible, requires manual approval to clear, and offers the customer no remediation. Because deferral is driven by instance-wide load rather than by anything the project controls, the failure presents as intermittent and correlates with business hours. The `concurrency_limit -> { 200 }` values on the policy sync workers were introduced by "Add concurrency limits and deduplication to MR policy sync workers" (2026-07-07). The 90 second deadline predates them. ### Output of checks \<!--Observed on GitLab.com; not applicable to a self-managed instance.--\>