❗[버그][관리자][물품관리] 물품 삭제 시 trade_request_history FK 제약조건 위반으로 500 에러 발생

[Cassiiopeia]

🗒️ 설명

• Admin 페이지에서 물품(Item) 삭제 요청 시 500 에러가 발생한다
• trade_request_history 테이블 삭제 시 chat_room 테이블에서 해당 trade_request_history_id를 참조하고 있어 FK 제약조건 위반이 발생한다
• 에러 메시지: update or delete on table "trade_request_history" violates foreign key constraint "fknh0lbb6idicc0mr9r3dghm55y" on table "chat_room"

🔄 재현 방법

1. Admin 페이지(/admin/items)에 로그인
2. 물품 목록에서 특정 물품의 삭제 버튼 클릭
3. POST /api/admin/items/delete API 호출됨
4. 해당 물품에 연결된 거래 요청(trade_request_history)이 있고, 그 거래 요청을 참조하는 채팅방(chat_room)이 존재하면 500 에러 발생

📸 참고 자료

에러 로그:

could not execute statement [ERROR: update or delete on table "trade_request_history" violates foreign key constraint "fknh0lbb6idicc0mr9r3dghm55y" on table "chat_room"
  Detail: Key (trade_request_history_id)=(e604d1de-f6ca-4f5e-be93-b2d9bb14bfb2) is still referenced from table "chat_room".]

요청 정보:

• 엔드포인트: POST /api/admin/items/delete
• Content-Type: multipart/form-data
• 요청 파라미터: itemId=faba1143-6b01-4d45-994b-6770a558d8e8

✅ 예상 동작

• 물품 삭제 시 관련된 하위 엔티티(trade_request_history, chat_room 등)가 올바른 순서로 삭제되거나, 연관 데이터 처리 후 물품이 정상적으로 삭제되어야 한다

⚙️ 환경 정보

• OS: Windows 10
• 브라우저: Chrome 142

🙋‍♂️ 담당자

• 백엔드: @Chuseok22
• 프론트엔드: 이름
• 디자인: 이름

[github-actions]

Chuseok22 Issue Helper

브랜치명

20260406_#627_물품_삭제_시_trade_request_history_FK_제약조건_위반으로_500_에러_발생

커밋 메시지

물품_삭제_시_trade_request_history_FK_제약조건_위반으로_500_에러_발생 : feat : {변경 사항에 대한 설명} https://github.com/TEAM-ROMROM/RomRom-BE/issues/627

[Chuseok22]

확인했습니다

[Cassiiopeia]

@Chuseok22 다음 보고서 확인 부탁드립니다

📌 구현 방향 정리 (Phase 1)

브레인스토밍을 거쳐 아래 방향으로 구현 예정입니다. Phase 1에서는 FK 에러 해결 + 관리자 삭제 경로의 Soft Delete 정상화에 집중하고, 채팅방 UX / 알림 고도화 / 데이터 보존 정책은 후속 이슈 #629로 분리했습니다.

---

🔍 코드 조사 결과 (중요)

현재 코드베이스를 확인해보니, Item 엔티티에는 이미 isDeleted 필드와 Soft Delete 인프라가 구축되어 있습니다.

Item.java:102        private Boolean isDeleted = false;
ItemRepository.java  softDeleteAllByMemberId(memberId)
                     // UPDATE Item i SET i.isDeleted = true WHERE ...
                     // 조회 쿼리에도 "AND i.isDeleted = false" 필터링 존재

또한 회원 탈퇴 로직(MemberApplicationService.deleteMember())은 이미 올바르게 구현되어 있습니다:

// 2. Chat 도메인 관련 데이터 삭제 (TradeRequestHistory 삭제 전에 먼저 처리)
chatRoomService.deleteAllChatRoomsByMemberId(memberId);

// 3. Item 도메인 관련 모든 데이터 및 모든 Item 삭제
itemService.deleteAllRelatedItemInfoByMemberId(memberId);  // 내부적으로 softDelete 사용

→ 회원 탈퇴는 chat_room을 trade_request_history보다 먼저 정리하므로 FK 에러 없음, Item은 Soft Delete 처리됨.

그러면 왜 관리자 삭제만 터지는가?

ItemService.deleteItemByAdmin()만 기존 Soft Delete 인프라를 쓰지 않고 deleteRelatedItemInfo()를 통해 trade_request_history를 Hard Delete하고 있기 때문입니다.

// ItemService.java:596
private void deleteRelatedItemInfo(Item item) {
    tradeRequestHistoryRepository.deleteAllByGiveItemItemId(item.getItemId());  // ❌ FK 위반
    tradeRequestHistoryRepository.deleteAllByTakeItemItemId(item.getItemId());  // ❌ FK 위반
    deleteItemImagesWithStorageFiles(item);
    embeddingService.deleteItemEmbedding(item.getItemId());
    likeHistoryRepository.deleteAllByItemId(item.getItemId());
}

// ItemService.java:677
public void deleteItemByAdmin(UUID itemId) {
    Item item = itemRepository.findById(itemId)...;
    deleteRelatedItemInfo(item);        // ❌ 여기서 FK 에러
    itemRepository.deleteByItemId(itemId);  // ❌ Hard Delete
}

deleteItemByAdmin()을 기존 Soft Delete 인프라를 사용하도록 교체하면 해결됩니다.

---

🎯 Phase 1 작업 범위

1. ItemService.deleteItemByAdmin() 로직 교체

• deleteRelatedItemInfo() 호출 제거 (해당 private 메서드는 deleteItem() 일반 사용자 경로에서만 사용)
• itemRepository.softDeleteById(itemId) 또는 동등한 Soft Delete 쿼리 호출
• 해당 Item을 give/take로 가진 TradeRequestHistory의 상태를 CANCELED로 일괄 변경 (기존 enum 재사용)
• trade_request_history, chat_room, chat_message는 삭제하지 않음 (보존)
• 거래 상대방들에게 임시 고정 문구 알림 발송: "관리자에 의해 물품이 삭제되었습니다"

2. Response DTO 점검

• 채팅방 / 거래내역 응답에서 item.isDeleted 값이 프론트에 전달되는지 확인
• 전달되지 않으면 최소한의 필드 노출 작업 추가 (프론트에서 Phase 2 UI 작업 시 참조)

3. Admin Docs 업데이트

• AdminControllerDocs에 @ApiChangeLog 추가 (Soft Delete 전환 반영)
• @Operation description에 "삭제 시 물품은 Soft Delete 처리되며, 관련 거래 요청은 CANCELED 상태로 변경됩니다" 명시

4. 알림 발송

• 기존 FCM 알림 인프라 재사용
• 대상: 해당 Item을 참조하는 모든 TradeRequestHistory의 give_item.member + take_item.member (중복 제거)
• 본문: Phase 1에서는 고정 문구 "관리자에 의해 물품이 삭제되었습니다"

---

⚠️ Phase 1에서 제외 (후속 이슈 #629로 분리)

• 채팅방 내부 삭제 물품 UI 플레이스홀더
• 채팅방 메시지 전송 차단 로직
• 삭제 사유 카테고리 enum (ItemDeletionReason) 및 Admin API 파라미터 추가
• 알림 본문 카테고리 기반 동적 생성
• 데이터 보존 정책 문서화 및 만료 배치

---

🤔 주요 설계 결정

TradeStatus 신규 상태 추가 vs CANCELED 재사용 → CANCELED 재사용

• 거래 흐름상 최종 상태가 동일 (취소)
• 상태 개수 증가 시 분기 로직이 전 영역에 퍼짐
• "왜 취소됐는지"는 Item의 isDeleted 값을 조인해서 확인 가능 → 정보 손실 없음

일반 사용자 deleteItem() 경로는 이번 이슈에서 건드리지 않음

• 같은 deleteRelatedItemInfo()를 공유하므로 잠재적으로 동일한 FK 에러 가능성 존재
• 다만 일반 사용자는 본인이 "거래 채팅방이 이미 생성된" 물품을 삭제하는 빈도가 낮을 것으로 추정 (재현 빈도 미확인)
• 이슈 ❗[버그][관리자][물품관리] 물품 삭제 시 trade_request_history FK 제약조건 위반으로 500 에러 발생 #627 스코프는 "관리자 삭제 500 에러"이므로 범위 준수
• 일반 사용자 경로의 동일 버그는 별도 이슈로 분리 검토 권장

DB 스키마 변경 불필요

• item.is_deleted 컬럼은 이미 존재
• Flyway 마이그레이션 불필요

---

🔗 후속 이슈

• 🚀[기능개선][관리자][물품관리][채팅] 관리자 삭제 물품에 대한 채팅방 UX 및 알림 고도화 #629 - Phase 2: 채팅방 UX / 알림 고도화 / 데이터 보존 정책

---

❓ 확인 필요 사항

1. 일반 사용자 deleteItem() 경로의 동일 FK 버그 가능성에 대해, 별도 이슈로 분리할지 이번에 함께 수정할지 결정 필요
2. 회원 탈퇴 로직에 남아있는 // TODO : TradeRequestHistory 도메인 관련 데이터 삭제 주석 → 탈퇴 시 trade_request_history가 어떻게 처리되어야 하는지도 함께 검토 필요 여부