🟡 [FEATURE] Add proper error handling and consistent HTTP status codes

[github-actions]

Description

Error handling is inconsistent across the API. Some errors return 500 with stack traces, others return null, and some throw uncaught exceptions.

Requirements

• Add @ControllerAdvice for global exception handling
• Return proper HTTP status codes (400, 404, 409, 422, 500)
• Consistent error response format (code, message, details)
• Never expose stack traces in production
• Log all errors with correlation IDs

Files Affected

• Need new: GlobalExceptionHandler.java
• All controllers need review

[github-actions]

🎯 Triage report

Error handling is inconsistent — some endpoints return 500 with stack traces, others return null. Requirements specify a GlobalExceptionHandler using @ControllerAdvice, standardized error response format, proper HTTP status codes, and suppression of stack traces in production.

📊 Assessment

Dimension	Value	Reasoning
Type	Feature	Adds new cross-cutting error handling infrastructure.
Labels	enhancement	Improves API reliability and security (no stack trace exposure).
Coding agent	Suitable	Clear pattern specified (@ControllerAdvice, consistent response format, no stack traces in prod). Affected files identified.

🔗 Similar issues

• 🟡 [FEATURE] Add input validation on all API endpoints #13 (related) — input validation (🟡 [FEATURE] Add input validation on all API endpoints #13) will also produce structured 400 errors; both should use the same error response format defined here.

💡 Notes and suggestions

Implement in this order: define error response DTO first, then create GlobalExceptionHandler, then update individual controllers. Ensure server.error.include-stacktrace=never is set in production profile. Correlation IDs can be implemented with MDC logging.

Generated by Daily Issue Triage · 95.1 AIC · ⌖ 18.2 AIC · ⊞ 5.4K · ◷

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/daily-issue-triage.md@1c6668b751c51af8571f01204ceffb19362e0f66

[github-actions]

🤖 This is an automated response from Test Improver.

This is a great opportunity for testing! A @ControllerAdvice exception handler is one of the more valuable things to test — it's cross-cutting infrastructure that, if broken, silently degrades the whole API.

Suggested Testing Strategy for Error Handling

Test the GlobalExceptionHandler directly with @WebMvcTest

`@WebMvcTest`(TaskController.class) // or any controller
class GlobalExceptionHandlerTest {

    `@Autowired` MockMvc mockMvc;

    `@MockBean` TaskService taskService;

    `@Test`
    void whenResourceNotFound_returns404WithStructuredBody() throws Exception {
        when(taskService.getTaskById(999L))
            .thenThrow(new ResourceNotFoundException("Task not found"));
        mockMvc.perform(get("/api/tasks/999"))
            .andExpect(status().isNotFound())
            .andExpect(jsonPath("$.code").value("NOT_FOUND"))
            .andExpect(jsonPath("$.message").value("Task not found"))
            .andExpect(jsonPath("$.stackTrace").doesNotExist()); // no stack traces!
    }

    `@Test`
    void whenUnexpectedError_returns500WithoutStackTrace() throws Exception {
        when(taskService.getTaskById(anyLong()))
            .thenThrow(new RuntimeException("DB is down"));
        mockMvc.perform(get("/api/tasks/1"))
            .andExpect(status().isInternalServerError())
            .andExpect(jsonPath("$.stackTrace").doesNotExist());
    }
}

Key scenarios to test

Scenario	Expected HTTP	Notes
Resource not found	404	Custom ResourceNotFoundException
Validation failure (after #13)	400	MethodArgumentNotValidException
Conflict (duplicate)	409	e.g., duplicate username
Unhandled RuntimeException	500	Must not expose stack trace
Response format consistency	any	All errors should share the same JSON shape

Currently documented bugs

The existing @WebMvcTest tests in PRs #52, #54, and #56 already pin the current incorrect status codes (e.g., 200 instead of 404 on missing resource). Once GlobalExceptionHandler is implemented and proper status codes are returned, those bug-pin tests will naturally fail — which is exactly what we want. That signals the bugs are fixed. We can then update those assertions to expect the correct codes.

Tip: ensure server.error.include-stacktrace=never

This belongs in application.properties (production profile) and should have a test that checks the error response body contains no stackTrace key — defending against the Spring Boot default accidentally being re-enabled.

Happy to implement the handler tests once the feature PR is ready. 🚀

Generated by Test Improver · 49.8 AIC · ⌖ 6.45 AIC · ⊞ 10.9K · ◷
_{Comment /test-assist to run again}

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/test-improver.md@1c6668b751c51af8571f01204ceffb19362e0f66