GitLab: MR creation race — 400 source_branch does not exist immediately after a successful push (no retry)

[vincentjames501]

How are you running Renovate?

Self-hosted Renovate CLI

Which platform you running Renovate on?

GitLab (.com or self-hosted)

Which version of Renovate are you using?

43.242.2

Please tell us more about your question or problem

Describe the bug

When Renovate pushes a branch and immediately creates the merge request, GitLab
occasionally rejects the MR-create call with:

POST /api/v4/projects/:id/merge_requests
=> 400  {"message": {"source_branch": ["does not exist"]}}

even though the preceding git push returned success and Renovate logged
INFO: Branch created. The MR POST is sent only tens of milliseconds after the
push completes, before GitLab (Gitaly) has made the new ref visible to the API —
a classic eventual-consistency race.

The request is not retried (retryCount=0), so Renovate logs
Pull request creation error and continues, leaving an orphaned branch with no
merge request. The branch is created on the remote and self-heals on the next
Renovate run (the ref is visible by then), confirming the failure is purely transient.

This is intermittent and load/timing dependent: in a single run, 10 of 24 branches
failed this way while the identical branch names succeeded in other repositories
processed earlier in the same run.

We only wish to run this biweekly and not everyday.

Expected behavior

A 400 {"source_branch": ["does not exist"]} immediately after a successful push
should be treated as a transient/eventual-consistency error and retried a few
times with a short backoff before being surfaced as a failure, so the MR is
created in the same run instead of leaving an orphaned branch until the next run.

Proposed solution

In the GitLab platform's createPr, detect this specific transient response
(HTTP 400 with body {"message":{"source_branch":["does not exist"]}}) and retry
the MR creation with a bounded exponential backoff (e.g. 3 attempts, ~0.5–2 s).
Optionally expose the attempt count / delay as a self-hosted config option. A
generic retry is not required — scoping it to this known GitLab response keeps it safe.

Additional context

• gitUrl: 'ssh' and prCreation: 'not-pending' can reduce the window but don't
  address the root race for prCreation: 'immediate' (the default).
• Affects self-managed GitLab where Gitaly ref propagation lags the HTTPS push.

Logs (if relevant)

logs

2026-06-25T07:11:34.090Z DEBUG: git push
2026-06-25T07:11:34.139Z INFO: Branch created
2026-06-25T07:11:34.146Z DEBUG: Creating Merge Request: Update dependency internal-lib to v1
2026-06-25T07:11:34.215Z DEBUG: POST .../merge_requests = (code=ERR_NON_2XX_3XX_RESPONSE, statusCode=400 retryCount=0, duration=67)
2026-06-25T07:11:34.216Z "statusCode": 400,
2026-06-25T07:11:34.216Z "body": {"message": {"source_branch": ["does not exist"]}}
2026-06-25T07:11:34.217Z DEBUG: Pull request creation error
(~56 ms between git push returning and the MR POST; whole window ~125 ms)

[RahulGautamSingh]

Renovate's http layer already has retry infra I think wrapWithRetry function we could use that.

[RahulGautamSingh]

Issue Created: #44498

PR welcome

[vincentjames501]

Yes. That seems like it would work nicely!