[feature] exception handling

[hil679]

📌 작업 내용

• 예외 핸들링

🧩 기능 상세

• validation 추가
• 각 Client에 대응하는 Fallback 클래스 구현 (에러 발생 시 로그 출력 및 빈 객체 반환 등)
  • order-service.yml에 order 전용 Circuit Breaker 임계치 설정 (실패율, 타임아웃 등)
• order create 예외 핸들링 필요

🧪 테스트 계획

• 중복 데이터 검증
• 예외 상황 (API 오류, 데이터 누락 등)

참고 사항 (선택)

• 관련 PR: #
• 참고 링크:
• 메모:

[coderabbitai]

📌 팔로업: 재고 차감 후 보상 트랜잭션 누락 (PR #9)

PR #9 코드 리뷰 중 발견된 이슈입니다. (요청자: @hil679)

문제 설명

OrderCommandServiceImpl.createOrder()에서 hubInventoryClient.decreaseHubInventory() 호출 이후, 아래 구간 중 어느 지점에서 예외가 발생해도 재고 복구 로직이 실행되지 않습니다.

hubInventoryClient.decreaseHubInventory(...)  ← 재고 차감
Order.create(...)                              ← 실패 시 복구 없음
orderRepository.save(order)                   ← 실패 시 복구 없음
deliveryClient.createDelivery(...)            ← FeignException만 복구됨

현재는 deliveryClient.createDelivery()의 FeignException에 대해서만 restoreHubInventory()를 호출하고 있습니다.
Order.create()나 orderRepository.save()가 실패하면 DB 트랜잭션은 롤백되지만 외부 서비스(hub-inventory)의 재고는 감소한 채로 남게 됩니다.

개선 방향

• decreaseHubInventory() 이후 전체 구간을 하나의 try/catch로 감싸서 어떤 예외든 restoreHubInventory()를 실행하도록 수정
• order.getOrderItems() 대신 inventoryInfos와 orderCreateCommand.orderItems()를 사용하여 RestoreHubInventoryCommand 목록을 구성 (Order 저장 실패 시에도 복구 가능하도록)

참고

• 관련 PR: 4 feature createorder #9
• 관련 리뷰 코멘트: 4 feature createorder #9 (comment)

[coderabbitai]

🔐 주문 삭제 권한 검증 누락 (팔로업)

PR #14 리뷰 중 발견된 사항입니다: #14 (comment)

요청자: @hil679

문제점

OrderCommandServiceImpl.deleteOrder(UUID userId, UUID orderId)에서 주문을 조회한 후, 요청한 userId가 실제로 해당 주문의 주인인지 검증하는 로직이 없습니다. orderId만 알면 누구나 다른 사용자의 주문을 삭제할 수 있는 보안 취약점이 있습니다.

해결 방안

방법 1 – 서비스 레이어에서 검증:

@Transactional
public void deleteOrder(UUID userId, UUID orderId) {
    Order order = orderRepository.findById(orderId).orElseThrow(
        () -> new BusinessException(NOT_FOUND_ORDER)
    );
    if (!order.getOrdererId().equals(userId)) {
        throw new BusinessException(OrderErrorCode.UNAUTHORIZED_ORDER_ACCESS);
    }
    order.deleteOrder(userId);
}

방법 2 – 도메인 레이어에서 검증:
Order.deleteOrder(UUID ordererId) 메서드 내에서 this.ordererId와 비교하여 권한 검증 후 super.delete() 호출.

추가 작업

• OrderErrorCode에 UNAUTHORIZED_ORDER_ACCESS (또는 FORBIDDEN_ORDER) 에러 코드 추가 필요
• 관련 단위 테스트 추가 필요

[coderabbitai]

PR #17 코드 리뷰에서 발견된 Validation 이슈

파일: src/main/java/com/fhsh/daitda/order/domain/vo/OrderItemInfo.java

문제:
OrderItemInfo.quantity 타입이 Integer에서 int 원시 타입으로 변경되어 타입 일관성 문제가 발생합니다.

• OrderProduct.quantity는 Integer 타입이며 @Column(nullable = false) 제약으로 DB 수준에서 null을 방지하고 있음
• OrderItemInfo.quantity를 int로 설정하면 타입 계약이 불일치함
• getQuantity() 메서드(Line 46)가 이미 Integer에서 int로 언박싱하고 있으며, getOrderItemInfo()에서도 같은 패턴이 반복됨

권장 수정:

 public record OrderItemInfo(
 	UUID productId,
 	String productName,
-	int quantity
+	Integer quantity
 ) {}

관련 PR 리뷰 코멘트: #17 (comment)
요청자: @hil679

[coderabbitai]

AdminOrderStrategy / UserOrderStrategy equal() 예외 처리 추가 필요

PR #17 리뷰에서 발견된 사항입니다. (관련 코멘트)

문제

• AdminOrderStrategy.equal() 및 UserOrderStrategy.equal() 에서 OrderAccessRole.from(auth)를 두 번 중복 호출하고 있습니다.
• 유효하지 않은 auth 문자열이 들어오면 IllegalArgumentException이 전파되어 전략 선택 루프가 정상적으로 동작하지 않습니다.

수정 방향

@Override
public boolean equal(String auth) {
    try {
        OrderAccessRole role = OrderAccessRole.from(auth);
        return role == OrderAccessRole.MASTER || role == OrderAccessRole.HUB_ADMIN;
    } catch (IllegalArgumentException e) {
        return false;
    }
}

UserOrderStrategy.equal()에도 동일한 패턴 적용 필요.

요청자: @hil679

[coderabbitai]

checkOrderer() null-safe 비교 누락 (팔로업)

PR #17 리뷰에서 발견된 사항입니다. (관련 코멘트)

요청자: @hil679

문제점

Order.checkOrderer(UUID userId)에서 this.ordererId.equals(userId)를 호출할 때 ordererId가 null이면 NullPointerException이 발생합니다.

public boolean checkOrderer(UUID userId) {
    if(!this.ordererId.equals(userId)) { // ordererId가 null이면 NPE 발생
        throw new BusinessException(NOT_MATCH_ORDERER);
    }
    return true;
}

수정 방향

Objects.equals()를 사용한 null-safe 비교로 변경:

 public boolean checkOrderer(UUID userId) {
-    if(!this.ordererId.equals(userId)) {
+    if(!java.util.Objects.equals(this.ordererId, userId)) {
         throw new BusinessException(NOT_MATCH_ORDERER);
     }
     return true;
 }

ordererId가 null인 경우에도 NPE 대신 BusinessException(NOT_MATCH_ORDERER)가 정상적으로 던져집니다.