Fix/4973 json error responses

[mehrdadbn9]

Fix #4973: Return JSON error responses instead of plain text

Problem

The Alertmanager API was returning error responses as plain text strings with incorrect Content-Type header:

• Content-Type: application/json
• Response Body: "bad matcher format: invalidfilter" (plain text string)
  This violates the JSON API specification as the response body is a quoted string, not a JSON object.

Solution

Updated the API to return proper JSON error responses with an error field:

• Content-Type: application/json
• Response Body: {"error":"bad matcher format: invalidfilter"} (valid JSON object)

Changes Made

1. OpenAPI Spec (api/v2/openapi.yaml)

   • Changed all error response schemas from type: string to JSON objects with error field
   • Added proper error body types for all error responses (400, 404, 500)

2. Swagger Code Generation

   • Regenerated REST API code with new error body types
   • Created proper error response structs:
     • GetAlertsBadRequestBody, GetAlertsInternalServerErrorBody
     • GetAlertGroupsBadRequestBody, GetAlertGroupsInternalServerErrorBody
     • GetSilencesBadRequestBody, GetSilencesInternalServerErrorBody
     • GetSilenceInternalServerErrorBody
     • DeleteSilenceInternalServerErrorBody
     • PostAlertsBadRequestBody, PostAlertsInternalServerErrorBody
     • PostSilencesBadRequestBody

3. API Handlers (api/v2/api.go)

   • Updated all error handlers to create error body objects instead of passing raw strings
   • Fixed the following endpoints:
     • GET /api/v2/alerts
     • POST /api/v2/alerts
     • GET /api/v2/alerts/groups
     • GET /api/v2/silences
     • GET /api/v2/silences/:silence_id
     • DELETE /api/v2/silences/:silence_id
     • POST /api/v2/silences

Example

Before

$ curl -v "http://localhost:9093/api/v2/alerts/groups?filter=invalidfilter"
< HTTP/1.1 400 Bad Request
< Content-Type: application/json
"bad matcher format: invalidfilter"

[siavashs]

Code generation command was not run correctly, hence the copyright header is removed.
You must only use the provided make target to regenerate code.
(This issue has happened in all files, I'm only pointing out one as an example!)

[siavashs]

Let's use the same message in the logs and the api, for example:

			message := "Failed to compile receiver regex"
			logger.Debug(message, "err", err)
			errMsg := fmt.Sprintf("%s: %v", message, err)
			return alert_ops.NewGetAlertsBadRequest().WithPayload(
				&alert_ops.GetAlertsBadRequestBody{
					Error: &errMsg,
				},
			)

[siavashs]

While this is a fix, I'm hesitant to break the API as it can cause problems for custom tools or automations that people use to integrate with Alertmanager API.

[siavashs]

Reopening the original PR after closing the new one the contributor had opened.
Please continue all updates and discussions here and avoid opening new PRs to fix the exact same issue.

Please see this guide on contributing to projects: https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-open-source#working-with-project-maintainers

• When feedback arrives about your pull request, respond promptly and professionally even if criticism feels harsh. Maintainers are typically focused on code quality.
• If changes are requested for your pull request, don't open a new pull request to address the changes. Keeping the existing pull request open and making changes there helps prevent the maintainers from losing context.
• If your pull request remains unaddressed for weeks, politely follow up with a comment requesting feedback. Do not directly mention the handles of maintainers. Maintainers often balance open source work with full-time responsibilities, and understanding their time constraints fosters better collaboration.
• If your contribution does not get accepted, ask the maintainers for feedback so that you can have that context for the next time you want to make a contribution.