Use appropriate error HTTP method and response codes for unmergeable MRs
What does this MR do and why?
This changes the HTTP method and response code returned for the REST API call PUT /projects/:id/merge_requests/:merge_request_iid/merge
when the MR still requires approval.
- Previously, GitLab used the
PUT
method and would return405 Method Not Allowed
if the MR requires approval, but200 OK
if merged or a different error on error- The
405 Method Not Allowed
was misleading, indicating that thePUT
method was incorrect, when in fact the state of the MR was the blocker
- The
- After this change:
- The
PUT
method will always return405 Forbidden
- The
POST
method is required - GitLab will return
403 Forbidden
if the MR requires approval
- The
My rationale for this change: the 405 Method Not Allowed
indicates that the PUT
method itself is not allowed for this endpoint:
The HyperText Transfer Protocol (HTTP) 405 Method Not Allowed response status code indicates that the server knows the request method, but the target resource doesn't support this method.
— Source
It seems more appropriate to return 403 Forbidden
, since the user is not allowed to merge until the required approvals have been granted:
The HTTP 403 Forbidden response status code indicates that the server understands the request but refuses to authorize it.
This status is similar to
401
, but for the403 Forbidden
status code, re-authenticating makes no difference. The access is tied to the application logic, such as insufficient rights to a resource.
— Source
This addresses #196730
How to set up and validate locally
- Create an MR
- Add at least one required review from another user or group
- Attempt to merge the MR using the REST API by calling
POST /projects/:id/merge_requests/:merge_request_iid/merge
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.