Give custom exceptions a @ResponseStatus fallback so unwritable-body errors resolve correctly

When a client sends an un-negotiable Accept (e.g. application/xml) on an error path, the
@ExceptionHandler runs and builds its JSON body, but the write fails with
HttpMediaTypeNotAcceptableException. Spring does not re-enter @ExceptionHandler resolution
for an exception raised inside exception handling, so the original ResourceNotFoundException
/ InsufficientStockException propagated to the container as a 500.

Spring's built-in exceptions implement ErrorResponse and self-resolve body-lessly in this
case; our custom RuntimeExceptions had no fallback. Annotating them with @ResponseStatus
lets ResponseStatusExceptionResolver answer with the right status (404 / 409) body-lessly.
The @ExceptionHandler still wins for normal requests, so the uniform {status,error,message}
body — and the recorded 63-case suite (all Accept: */*) — is unchanged.

Also drop handleNotAcceptable: it never fired (the write failure isn't re-entrant), and
success-path 406 is already produced by Spring's built-in negotiation.

Signed-off-by: dhananjay6561 <dhananjayaggarwal6561@gmail.com>

Author: dhananjay6561

spring-boot-product-catalog/src/main/java/io/keploy/productcatalog/web/error/GlobalExceptionHandler.java

@@ -6,7 +6,6 @@
 import org.springframework.http.ResponseEntity;
 import org.springframework.http.converter.HttpMessageNotReadableException;
 import org.springframework.validation.FieldError;
-import org.springframework.web.HttpMediaTypeNotAcceptableException;
 import org.springframework.web.HttpMediaTypeNotSupportedException;
 import org.springframework.web.HttpRequestMethodNotSupportedException;
 import org.springframework.web.bind.MethodArgumentNotValidException;
@@ -113,14 +112,6 @@ public ResponseEntity<Map<String, Object>> handleNoResource(NoResourceFoundExcep
         return ResponseEntity.status(HttpStatus.NOT_FOUND).body(body);
     }
 
-    @ExceptionHandler(HttpMediaTypeNotAcceptableException.class)
-    public ResponseEntity<Void> handleNotAcceptable(HttpMediaTypeNotAcceptableException ex) {
-        // Thrown while writing a response body the client's Accept header can't take (e.g. an error
-        // hit with Accept: application/xml). This MUST be body-less — the body is exactly what can't
-        // be negotiated — otherwise it recurses and the catch-all below would mislabel it as a 500.
-        return ResponseEntity.status(HttpStatus.NOT_ACCEPTABLE).build();
-    }
-
     @ExceptionHandler(Exception.class)
     public ResponseEntity<Map<String, Object>> handleUnexpected(Exception ex) {
         // Catch-all backstop: any exception without a more specific handler above still returns the

spring-boot-product-catalog/src/main/java/io/keploy/productcatalog/web/error/InsufficientStockException.java

@@ -1,5 +1,14 @@
 package io.keploy.productcatalog.web.error;
 
+import org.springframework.http.HttpStatus;
+import org.springframework.web.bind.annotation.ResponseStatus;
+
+// @ResponseStatus is a fallback: for a normal request the @ExceptionHandler in
+// GlobalExceptionHandler wins and returns the uniform {status,error,message} body. But if the
+// body can't be written (e.g. the client sent Accept: application/xml), that write failure is not
+// re-entrant into @ExceptionHandler resolution, so ResponseStatusExceptionResolver uses this
+// status to answer body-lessly with 409 instead of letting the exception surface as a 500.
+@ResponseStatus(HttpStatus.CONFLICT)
 public class InsufficientStockException extends RuntimeException {
     public InsufficientStockException(String message) {
         super(message);

spring-boot-product-catalog/src/main/java/io/keploy/productcatalog/web/error/ResourceNotFoundException.java

@@ -1,5 +1,14 @@
 package io.keploy.productcatalog.web.error;
 
+import org.springframework.http.HttpStatus;
+import org.springframework.web.bind.annotation.ResponseStatus;
+
+// @ResponseStatus is a fallback: for a normal request the @ExceptionHandler in
+// GlobalExceptionHandler wins and returns the uniform {status,error,message} body. But if the
+// body can't be written (e.g. the client sent Accept: application/xml), that write failure is not
+// re-entrant into @ExceptionHandler resolution, so ResponseStatusExceptionResolver uses this
+// status to answer body-lessly with 404 instead of letting the exception surface as a 500.
+@ResponseStatus(HttpStatus.NOT_FOUND)
 public class ResourceNotFoundException extends RuntimeException {
     public ResourceNotFoundException(String message) {
         super(message);