Concurrent Merge Retries

Code Storage merge requests now handle target branch movement more gracefully for high-concurrency workflows.

When you call repo.merge() without expectedTargetSha, native Code Storage targets may retry stale target updates internally. That means multiple workers can merge into the same branch without every clean merge race turning into an immediate 409.

const result = await repo.merge({
  sourceBranch: 'feature/preview',
  targetBranch: 'main',
  strategy: 'merge',
  commitMessage: 'Merge feature/preview',
  author: { name: 'Merge Bot', email: 'merge@example.com' },
});

Retries keep the source commit pinned after the first attempt. If new commits land on the source branch while Code Storage is retrying, they are not pulled into the merge by accident; each retry merges the same source commit against the latest target tip.

You can still pass expectedTargetSha when you want strict optimistic concurrency. In that mode, a target branch move fails the merge instead of retrying it.

Automatic stale-target retry is only enabled for native Code Storage targets. GitHub-backed public targets keep the existing single-attempt behavior, and true Git merge conflicts still return 409.

Conflict responses now include a machine-readable conflict_type, so callers can distinguish file conflicts from retry exhaustion:

{
  "error": "merge conflict",
  "conflict_type": "merge_conflict",
  "conflict_paths": ["docs/example.md"],
  "merge_base_sha": "a2d127e6a4d54bb7390de828a99e36411f0c84df"
}

conflict_type can be merge_conflict, target_moved, or repo_changed.

See the docs