CommitStatusApi silently suppresses errors without logging or visibility

Incorrect HTTP Status Code for Server Errors in Commit Status API

Problem

The Commit Status API is currently returning a 400 (Bad Request) status code for server-side errors, which is incorrect according to HTTP standards. A 400 status code should only be used when the client has made an invalid request.

Current Implementation

In the code:

• Location: https://gitlab.com/gitlab-org/gitlab/-/blob/20c4fd6d72449b65aea9c6218c8f00f081f00d16/app/services/ci/pipelines/add_job_service.rb#L28
• All StandardErrors are being rescued without logging
• Server errors are incorrectly returning bad_request status: https://gitlab.com/gitlab-org/gitlab/-/blob/20c4fd6d72449b65aea9c6218c8f00f081f00d16/app/services/ci/create_commit_status_service.rb#L39

Expected Behavior

• Server-side errors should return appropriate 5xx status codes (typically 500)
• Errors should be properly logged for debugging purposes
• 400 status code should only be returned for actual client-side errors

Impact

• Misleading error responses to API consumers
• Potential difficulties in debugging due to lack of error logging
• Incorrect error handling may mask serious server-side issues

Specific condition

https://gitlab.com/gitlab-com/request-for-help/-/issues/3097#note_2634840489

{"message":"Cannot transition status via :enqueue from :pending (Reason(s): Status cannot transition via "enqueue")"}

we can skip the update to pending if it's already pending and return a 200 instead of a 201 to make the update idempotent. But we need to consider if it breaks the existing contract too much.

Proposal

The work is broken down into several child items which can be implemented in order.

1. Track and raise in dev and errors
2. Handle invalid transitions in Commit Status POST api
3. Don't return detailed code generated errors messages via api