Add rate limit to index integrity worker
What does this MR do and why?
Summary
This change adds rate limiting to a background worker that checks the integrity of the search index for projects and groups.
Previously, every search request could trigger a background job to verify that the search index was in sync — with no restrictions on how often this could happen. Now, this integrity check is limited to once per hour per project or group, preventing the same check from being triggered repeatedly in a short time window.
If the rate limit is hit, the system logs a message and skips the job rather than queuing it again. The rate limiting is scoped independently, meaning different projects and groups each have their own separate hourly allowance.
The accompanying tests verify that the worker fires on the first request, is skipped on subsequent requests within the same hour, and fires again once the hour window has passed — for both project-level and group-level searches.
References
Screenshots or screen recordings
| Before | After |
|---|---|
How to set up and validate locally
- Create group with projects
- Trigger zero-result search (first call)
http://127.0.0.1:3000/search?group_id=<ID>&scope=blobs&search=nonexistent - Check Sidekiq: NamespaceIndexIntegrityWorker enqueued
- Trigger again (second call) and see Same search within 1 hour and worker NOT enqueued
- Verify logs
tail -f log/application_json.log | grep 'search_index_integrity rate limit hit' - Test expiry
Gitlab::Redis::RateLimiting.with { |r| r.flushdb }and Repeat search → worker enqueued again.
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.