Distinguish between validation errors and stale resources errors when Runner requests a new job
What does this MR do?
Split 'conflict' and 'validation error' case for job scheduling
When job is being scheduled, GitLab tries to detect concurrent requests that would get the same job. In that case only the first Runner that asked for a job gets it, and all other requests are internally handled again (until there are other jobs in the queue that matches such specific Runner).
When such "conflict" situation was detected and no job was found in the loop repeat, Runner receives a 409 Conflict
response, which leaves a track about such situation. It additionally triggers a request back-off on Runner, so in highly concurrent installations it should generate some intervals between concurrent requests from different Runners.
However, one of the symptoms used for finding the "conflict" situation is the StateMachines::InvalidTransition
exception, which may be also thrown when some data doesn't pass validation. This is a case that should definitely not produce a 409 Conflict
response, but instead a 400 Bad Request
one with details about what was wrong should be sent.
This commit adds a needed update to the Ci::RegisterJobService
service and the /api/v4/jobs/request
endpoint.
More details about the problem and why we'fe decided to handle it like that can be found at gitlab-runner#4360 (closed) and especially at gitlab-runner#4360 (comment 200280465) comment.
Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because _____.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team