## Background When External Status Checks were introduced, the only possible states were: 1. Pending response. 1. Received response, which indicated [pass](https://gitlab.com/gitlab-org/gitlab/-/issues/329636#note_654394212). In other words, there was no way to indicate failure. This was done for the [sake of simplicity/iteration](https://gitlab.com/gitlab-org/gitlab/-/issues/327634#note_563430395). API clients, as well as the API itself, assume that every request from the client represents `passed`. A failure state was implemented later, under https://gitlab.com/gitlab-org/gitlab/-/issues/329636. For the sake of backward compatibility with existing API clients, the status parameter had a default of `passed`. ## Problem to solve For the External Status Checks API, a default status of `passed` basically means, "when in doubt, assume the MR can proceed". From a compliance perspective, we should assume the opposite. ## Proposal For External Status Checks, the `status` param should not have a default value. Requests without this param should receive a response of 400 Bad request. This is a breaking change, as [discussed in a related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/329636#note_653730297), so must be made in a major release.