Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab FOSS GitLab FOSS
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1
    • Merge requests 1
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLab FOSSGitLab FOSS
  • Merge requests
  • !8760

Fix CI requests concurrency

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Kamil Trzciński | OoO 2022.07.23 till 2022.08.20 requested to merge fix-ci-requests-concurrency into master Jan 24, 2017
  • Overview 20
  • Commits 5
  • Pipelines 4
  • Changes 5

What does this MR do?

This fixes a bug introduced by https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8084.

When we try to update a build, we load it's representation to the memory, in between another update can happen by another Runner. Since we use optimistic locking we will receive an exception stating that our copy of the object is old (StaleObjectError). This exception makes us return nil from RegisterBuildService to builds/register handler.

Since we received nil we assume that we did not found a new build, so, the build queue is empty. However, this is not true, because we only failed to update the existing build.

Runner then will receive the latest value of runner queue (after change), and next time when we ask the builds/register.json we will hit the happy path of processing, assuming that there were no changes to build queue since the last time.

This bug affects GitLab Runners from 1.9.0-rc5 to 1.10.x

Does this MR meet the acceptance criteria?

  • Changelog entry added
  • Tests added for this feature/bug

What are the relevant issue numbers?

None yet.

Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: fix-ci-requests-concurrency