<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=446176) </details> <!--IssueSummary end--> <!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Problem to solve Geo accelerates CI runners by allowing them to clone from secondary sites. However, the clone for the first stage of the pipeline is almost always proxied to the primary site. This is because the verification of the replicated changes (such as pipeline ref) has not been completed by the time the first stage of the pipeline is executed. Typically it takes about 90 seconds for the verification to complete on a lightly loaded deployment. This issue is a follow on from discussions had [here](https://gitlab.com/gitlab-org/gitlab/-/issues/415179#note_1752250854) ### Proposal Ensure that the clone for the first stage of the pipeline is guaranteed or has a higher chance of being served from a secondary site. Some options that have been discussed: - The decision to proxy the request to the primary is not made on the status of verification but instead on the status of replication - Delay the clone request at the secondary site until replication and verification is complete. ### Intended users * [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator)