Call Gitaly for fetching refs when Redis cache is stale in pipelines creation
What does this MR do and why?
This MR introduces a new feature flag branches_and_tags_without_cache_pipelines that implements a more robust branch and tag existence checking mechanism for pipeline creation validation. It adds fallback logic that bypasses potentially stale Redis cache when determining if branches or tags exist.
Why it's needed:
GitLab's current branch/tag existence checking relies on Redis-cached data (branch_names and tag_names sets) for performance. However, this cache can become stale due to:
- Race conditions between multiple concurrent push operations.
-
Asynchronous cache invalidation via background workers (
PostReceiveWorker). - External Git operations that bypass GitLab's cache invalidation.
- Lock acquisition failures during cache refresh operations.
- Distributed system delays across multiple GitLab instances.
When stale cache incorrectly reports that a branch/tag doesn't exist, it can cause pipelines to fail in the Gitlab::Ci::Pipeline::Chain::Validate::Repository step with a Reference not found exception.
The solution:
The new implementation uses a defensive fallback strategy:
- First attempt: Check using existing cached method (fast path)
- On cache miss: Don't trust the cache - expire it and query Gitaly directly
- Cache refresh: Fresh data from Gitaly is automatically cached for future use
- Monitoring: Log cache mismatches to track inconsistency frequency
This ensures authoritative data for critical operations while maintaining performance for the majority of cases where the cache is consistent.
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.