Concurrent commits to seperate files fails
Summary
I have multiple processes on seperate nodes committing seperate files into a git repo concurrently. The file paths are not conflicting.
When concurrently hitting the projects/(project number)/repository/commits, some processes get a 400 with a message:
{"message":"9:reference update: reference does not point to expected object."}
Steps to reproduce
This can be reproduced consistently, using the api directly or a client:
[TestMethod]
public async Task Test()
{
PostCommitRequest GenerateRequest(int i)
{
var rand = new Random().NextInt64();
var encoding = "text";
var req = new PostCommitRequest
{
Branch = "main",
CommitMessage = "I am a commit: " + rand,
Actions = new[]
{
new ActionHash()
{
Action = "create",
FilePath = "path/" + rand,
Encoding = encoding,
Content = "I am a file: " + rand
}
}
};
return req;
}
var tasks = Enumerable.Range(0, 5)
.Select(i =>
Task.Run(async () =>
{
var client = new GitLabClient(hostUrl: "<our gitlab url>", authenticationToken: "<an auth token>");
var request = GenerateRequest(i);
await GitlabApiClientFactory.PostCommit(client: client, projectId: <a project id>, request: request);
}));
await Task.WhenAll(tasks);
}
Example Project
This can be found with any empty project. I am using gitlab enterprise (The TradeDesk).
What is the current bug behavior?
Failure to commit simultaneously to the same project/branch, even if there are no conflicts between the commits.
What is the expected correct behavior?
It seems like the gitlab API should be able to queue the commits, or otherwise handle non-conflicting concurrent creations of commits that don't specify a base commit.
Known workaround:
I am aware of a simple workaround - retry logic does prevent this issue, but isn't ideal. Do you consider this a bug?
Environment:
ComponentsUpdate ASAP GitLabv16.4.1-ee GitLab Shell14.28.0 GitLab Workhorsev16.4.1 GitLab APIv4 GitLab Pages16.4.1 GitLab KASv16.4.0 GeoPrimary site Ruby3.0.6p216 Rails7.0.6 PostgreSQL (main)13.11 PostgreSQL (ci)13.11 Redis6.2.6