GitLab should not index conflicting commit ranges in parallel
It's possible for multiple
ElasticCommitIndexerWorker to be running in parallel and depending on timing an older job may finish later than a newer job and it could possibly mean that you overwrite the index with stale content.
It's also very wasteful to run multiple of these for the same project at the same time.
Steps to reproduce
Push to the default branch of the same project very frequently.
What is the current bug behavior?
Multiple workers run at the same time for the same project.
What is the expected correct behavior?
Only one worker should be triggered and we should ensure when we start indexing we're indexing the latest changes. Otherwise we should serialise them so a newer worker (for the later SHA) won't even kick off until we finish the older indexing.