fix: Return errors inside JSON objects

[sanbotto]

Summary by CodeRabbit

• Improvements
  • Error responses from the API are now consistently returned in JSON format across all error scenarios (validation failures, unavailable endpoints, rate limiting, timeouts), providing standardized error handling for API clients.

[coderabbitai]

Walkthrough

A new helper function writeJSONError was introduced to standardize error responses across HTTP and WebSocket handlers. This function sets the appropriate Content-Type header to application/json, writes the provided HTTP status code, and encodes error messages in JSON format. Multiple existing http.Error() calls were replaced with this helper throughout the file, affecting error handling for request body failures, unavailable endpoints, timeouts, rate limits, and retry exhaustion. The refactoring maintains all existing success paths, retry logic, and endpoint selection behavior.

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: replacing plain text HTTP errors with JSON-formatted error responses throughout the server handlers.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/json-objects-for-errors

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

internal/server/server.go (1)

233-240: Consider documenting this as a breaking API change.

Switching from plain-text (http.Error) to JSON error responses changes the API contract. Clients that parse error bodies as plain text will need updates. Consider:

• Noting this in the changelog/release notes
• If semantic versioning is used, this warrants a minor (or major) version bump depending on your stability guarantees

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/server/server.go` around lines 233 - 240, The change from plain-text
errors to JSON in writeJSONError is a breaking API change for clients expecting
text bodies—update project release notes/changelog to document this behavior
change and state migration guidance (clients should parse JSON {"error":
"..."}), and if you follow semver bump the version appropriately (minor or major
depending on stability guarantees); mention the writeJSONError function
explicitly and include suggested client update steps and the rationale in the
release text.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@internal/server/server.go`:
- Around line 233-240: The change from plain-text errors to JSON in
writeJSONError is a breaking API change for clients expecting text bodies—update
project release notes/changelog to document this behavior change and state
migration guidance (clients should parse JSON {"error": "..."}), and if you
follow semver bump the version appropriately (minor or major depending on
stability guarantees); mention the writeJSONError function explicitly and
include suggested client update steps and the rationale in the release text.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: f681179b-cf21-4d8c-9242-7173bfc2c54d

📥 Commits

Reviewing files that changed from the base of the PR and between 5afec46 and b18cf26.

📒 Files selected for processing (1)

• internal/server/server.go