🐛 Fix: 구매제안 채팅방 생성

[Chungs0604]

🔗 관련 이슈

• 미판매 + 거래제안, 제안 승인 시 채팅방 생성 수정 #404

📌 작업 내용

• 판매 등록(Product) 없이 구매 제안(PurchaseOffer)만으로 시작된 채팅방 생성/조회 지원
• 구매 제안 수락(ACCEPTED) 후에도 채팅방 생성 가능하도록 수정
• PurchaseOffer 기반 거래는 Product가 없는 설계이므로, 채팅방 응답에서 product 관련 필드
  nullable 처리

📌 변경된 API

• POST /chats — productStatus, price, productId 필드 nullable 변경
  • 판매 등록 없는 아이템 + 구매 제안(SENT/ACCEPTED)인 경우 세 필드 null 반환
• GET /chats/{chatRoomId} — 동일하게 productStatus, price, productId nullable 변경

📌 테스트 결과

• ON_SALE 상품 → 채팅방 생성 200 ✅
• HIDDEN 상품 + SENT offer → 채팅방 생성 200 ✅
• 판매 등록 없는 아이템 + SENT offer → 채팅방 생성 200, product 필드 null ✅
• 판매 등록 없는 아이템 + ACCEPTED offer → 채팅방 생성/조회 200, product 필드 null ✅
• offer 없고 ON_SALE/TRADING도 아님 → 409 ✅
• SOLD 상품 + offer → 409 ✅
• 채팅방 목록 — 모든 케이스 정상 노출 ✅

📌 확인 필요 사항

• 프론트엔드: productStatus, price, productId null 처리 필요
  • productId null → 상품 상세 링크 미노출
  • price null → 가격 표시 미노출 또는 별도 처리

---

✅ 체크리스트

• 기능 요구사항을 충족했는가?
• API 응답 형식이 통일되어 있는가?
• 예외 상황이 적절히 처리되었는가?
• 인증/인가 검증이 누락되지 않았는가?
• Entity를 직접 응답하지 않았는가?
• 중복 코드가 과도하지 않은가?
• 메서드와 클래스의 역할이 명확한가?
• 테스트가 필요한 핵심 로직에 테스트가 작성되었는가?

[github-actions]

Gemini 파일 단위 요약 리뷰

src/main/java/com/tenure/domain/purchase/repository/PurchaseOfferRepository.java

변경 요약

• 제안자 ID, 소유자 ID, 아이템 ID 및 상태 목록(statuses)을 조건으로 구매 제안(PurchaseOffer)의 존재 여부를 확인하는 existsByProposerIdAndOwnerIdAndItemIdAndStatusIn 메서드를 추가했습니다.

영향 범위

• 기능 및 흐름: "구매 제안은 사용자당 아이템별 1회 제한" 정책을 검증하기 위해, 기존에 제안한 이력(특정 상태값들을 가진 이력)이 존재하는지 확인하는 비즈니스 로직에 영향을 줍니다.
• 계층: 영속성(Repository) 계층 및 이를 호출하는 서비스(Service) 계층에 영향을 줍니다.

확인 필요

• 없음

제안

• 성능 최적화를 위한 @Query 제거 및 쿼리 메서드 활용:
  현재 작성된 @Query("select count(po) > 0 ...") 방식은 DB에서 조건에 맞는 모든 레코드를 카운트하므로 데이터가 많아질 경우 성능 저하 우려가 있습니다. Spring Data JPA는 existsBy... 네이밍을 지원하며, 이를 사용하면 내부적으로 LIMIT 1을 사용하는 효율적인 EXISTS 쿼리를 자동 생성합니다. 따라서 아래와 같이 @Query 어노테이션을 제거하고 Spring Data JPA의 기본 쿼리 메서드 기능을 활용하는 것을 제안합니다.

  boolean existsByProposerIdAndOwnerIdAndItemIdAndStatusIn(
          Long proposerId,
          Long ownerId,
          Long itemId,
          Collection<PurchaseOfferStatus> statuses);

src/main/java/com/tenure/domain/chat/service/ChatRoomService.java

변경 요약

• 구매 제안(Purchase Offer) 존재 여부 검증 시, 단일 상태(SENT) 조회에서 복수 상태(SENT, ACCEPTED) 존재 여부(existsBy...) 확인 방식으로 쿼리를 최적화하고 대상을 확장했습니다.
• 판매 등록이 되지 않은 아이템(Product가 null인 상태)에서도 채팅방을 생성하거나 진입할 수 있도록, productRepository.findByItemId() 결과가 없을 때 예외를 던지는 대신 null을 반환하도록 수정했습니다.
• product가 null일 때 발생할 수 있는 NullPointerException을 방지하기 위해 삼항 연산자를 사용한 방어 코드를 추가했습니다.

영향 범위

• 기능: 제안(Offer) 기반의 채팅방 생성/조회(findOrCreateChatRoom) 및 채팅방 진입(enterChatroom) 흐름
• 계층: Service 레이어 (ChatRoomService) 및 Repository 레이어 (PurchaseOfferRepository, ProductRepository)
• 실행 흐름: 판매 등록(Product) 없이 아이템만 존재하는 상태에서 제안을 통해 채팅방으로 진입하는 비즈니스 흐름 지원

확인 필요

• findOrCreateChatRoom 메서드 내에서 product가 null이 될 수 있도록 변경됨에 따라, diff에 노출되지 않은 해당 메서드의 하위 라인에서 product 객체의 메서드(예: product.getId(), product.getSeller())를 직접 호출하여 NullPointerException이 발생할 위험이 없는지 전체 메서드 바디에 대한 검증이 필요합니다.

제안

• purchaseOfferRepository.existsByProposerIdAndOwnerIdAndItemIdAndStatusIn 호출 시 사용되는 List.of(SENT, ACCEPTED)는 자주 변경되지 않는 상태 그룹이므로, 서비스 클래스 내에 private static final List<PurchaseOfferStatus> ACTIVE_OFFER_STATUSES = List.of(SENT, ACCEPTED);와 같이 상수로 선언하여 재사용성과 가독성을 높이는 것을 제안합니다.

src/main/java/com/tenure/domain/chat/dto/response/ChatRoomResponse.java

변경 요약

• ChatRoomResponse.from 정적 팩토리 메서드 내에서 product 객체에 대한 Null-Safe 처리 추가
• product가 null일 경우 productStatus, price, productId 필드를 null로 설정하여 NullPointerException 방지

영향 범위

• 채팅방 정보를 반환하는 API 응답 생성 흐름
• 상품(Product)이 아직 등록되지 않은 아이템(Item) 기반 채팅방 조회 기능

확인 필요

• ChatRoomResponse 생성자의 파라미터 중 price와 productId가 원시 타입(int, long)이 아닌 래퍼 타입(Integer, Long)으로 정의되어 있는지 확인이 필요합니다. 만약 원시 타입으로 정의되어 있다면, null 전달 시 언박싱 과정에서 NullPointerException이 발생할 수 있습니다.

제안

• 상품이 없는 채팅방(예: 일반 아이템 문의 등)이 비즈니스 요구사항상 정상적인 케이스인지 재확인하고, 만약 항상 상품이 존재해야 하는 구조라면 null 처리를 하기보다는 이전 단계(서비스 레이어)에서 검증 예외를 던지는 것이 안전할 수 있습니다.