nessi/NexaPG
1
0
Fork 0
Code Issues 20 Pull Requests Actions Packages Projects Releases 12 Activity

[NX-101] Standardize API error response format across all endpoints #7

New Issue
Closed
opened 2026-02-13 13:11:48 +00:00 by nessi · 1 comment
nessi commented 2026-02-13 13:11:48 +00:00
Owner
Copy Link

Goal

Return a consistent error payload shape for all API errors.

Scope

  • Define a shared error schema (code, message, details, request_id).
  • Ensure 4xx/5xx responses follow this schema.
  • Replace ad-hoc HTTPException details where needed.

Acceptance Criteria

  • All endpoints return consistent JSON error structure.
  • Common error cases are documented.
  • Frontend can reliably parse and display errors.
## Goal Return a consistent error payload shape for all API errors. ## Scope - Define a shared error schema (code, message, details, request_id). - Ensure 4xx/5xx responses follow this schema. - Replace ad-hoc HTTPException details where needed. ## Acceptance Criteria - All endpoints return consistent JSON error structure. - Common error cases are documented. - Frontend can reliably parse and display errors.
nessi added this to the v1.0 - Stability, Reliability & Security (P0) milestone 2026-02-13 13:11:48 +00:00
nessi added the P0 label 2026-02-13 13:11:48 +00:00
nessi self-assigned this 2026-02-13 13:11:48 +00:00
nessi added reference development 2026-02-14 10:25:34 +00:00
nessi commented 2026-02-14 10:36:12 +00:00
Author
Owner
Copy Link

Implemented in commit: [NX-101 Issue] Refactor error handling to use consistent API error format.

Done

  • Introduced a shared API error payload format across backend responses:
    • code
    • message
    • details
    • request_id
  • Added centralized error helpers and request ID middleware/handlers.
  • Standardized 4xx/5xx responses (including validation and unhandled exceptions) to the same JSON shape.
  • Replaced ad-hoc HTTPException(detail="...") patterns in affected routes/services with structured error objects.
  • Updated target connectivity/discovery/ownership/not-found cases to return stable error codes.
  • Updated frontend API error parsing so UI can reliably consume code, details, and request_id.
  • Documented common API error codes and payload format in README.

Notes

  • Background collector connection failures remain log events (not API responses), while API endpoints now return consistent structured JSON errors.
  • Compile check passed: python -m compileall backend/app.

NX-101 acceptance criteria are met.

Implemented in commit: `[NX-101 Issue] Refactor error handling to use consistent API error format`. ## Done - Introduced a shared API error payload format across backend responses: - `code` - `message` - `details` - `request_id` - Added centralized error helpers and request ID middleware/handlers. - Standardized 4xx/5xx responses (including validation and unhandled exceptions) to the same JSON shape. - Replaced ad-hoc `HTTPException(detail="...")` patterns in affected routes/services with structured error objects. - Updated target connectivity/discovery/ownership/not-found cases to return stable error codes. - Updated frontend API error parsing so UI can reliably consume `code`, `details`, and `request_id`. - Documented common API error codes and payload format in README. ## Notes - Background collector connection failures remain log events (not API responses), while API endpoints now return consistent structured JSON errors. - Compile check passed: `python -m compileall backend/app`. NX-101 acceptance criteria are met.
nessi closed this issue 2026-02-14 10:36:12 +00:00
Sign in to join this conversation.
development
Branches Tags
Labels
Clear labels
P0
High priority
 P1
Medium priority
 P2
Low priority
No Label P0
Milestone
No items
No Milestone v1.0 - Stability, Reliability & Security (P0)
Projects
Clear projects
No project
Assignees
Clear assignees
nessi
No Assignees nessi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: nessi/NexaPG#7
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?