Summary

POST /~api/pulls/{requestId}/request-for-changes sets the caller's review to APPROVED rather than REQUESTED_FOR_CHANGES. It is functionally identical to POST /~api/pulls/{requestId}/approve.

Root cause

In server-core/src/main/java/io/onedev/server/rest/resource/PullRequestResource.java, requestForChanges() passes true for the approved parameter:

@Api(order=1450)
@Path("/{requestId}/request-for-changes")
@POST
public Response requestForChanges(@PathParam("requestId") Long requestId, String note) {
    var request = pullRequestService.load(requestId);
    var user = SecurityUtils.getUser();
    note = StringUtils.trimToNull(note);

    if (user == null)
        throw new UnauthorizedException();

    pullRequestReviewService.review(user, request, true, note);   // should be false

    return Response.ok().build();
}

PullRequestReviewService.review(User, PullRequest, boolean approved, String note) branches on that third argument, so the review is stored as APPROVED and a PullRequestApproveData change is recorded.

This appears to be a copy-paste error confined to the REST layer. Every other caller of review() passes the correct value:

Affected versions

Present since the endpoint was introduced in v16.2.1, and still present in v16.6.3 and on main. Verified by inspecting the tagged sources for v16.2.0 (endpoint absent), v16.2.1, v16.2.2, v16.2.3, v16.3.0, v16.4.0, v16.4.2, v16.5.0, v16.5.12, v16.6.0 through v16.6.3, and main.

Reproduced against a self-hosted v16.5.12 instance.

Steps to reproduce

1. Open a pull request and add a user as a reviewer.
2. As that user, request changes through the REST API:

curl -X POST -u "<login>:<token>" \
  -H 'Content-Type: application/json' \
  -d '"please address the review comments"' \
  "https://<server>/~api/pulls/<requestId>/request-for-changes"

3. Read the reviews back:

curl -u "<login>:<token>" "https://<server>/~api/pulls/<requestId>/reviews"

Expected: the reviewer's status is REQUESTED_FOR_CHANGES. Actual: the reviewer's status is APPROVED, and the pull request activity records an approval.

Requesting changes through the web UI on the same pull request behaves correctly, which confirms the defect is specific to the REST endpoint.