Feat/203 일정 삭제 정책 수정

[jaylovegood]

✨ Feature PR (to dev)

중요: Feat/202 PR을 먼저 리뷰 후 머지해주세요!!!!!!! 그 브랜치 위에 쌓은 거라서 base를 dev가 아닌 202 브랜치로 해놓았습니다. 202 먼저 머지하면 이 PR의 베이스가 자동으로 dev로 변경됩니다

🧪 로컬 테스트 여부 (작업자 체크)

• 로컬에서 Swagger 혹은 테스트 코드로 동작을 확인했습니다.

📄 documentation 최신화 여부

변경사항과 관련된 API의 swagger documentation이 실제 동작과 일치하는지 확인합니다.

• (작업자) 확인하였습니다.
• (리뷰어) 확인하였습니다.

📌 작업 내용(what & why)

• 삭제 로직 (EventService.delete())

  • CONFIRMED + WAITLISTED 신청자만 이메일 알림 대상 (BANNED 제외)
  • 삭제 전에 유저 정보 조회 → 이메일 데이터 구성
  • registrations 먼저 삭제 → event 삭제 (FK 제약)
  • afterCommit에서 이메일 발송 (트랜잭션 커밋 후 실행)
  • Pessimistic Lock으로 동시성 처리

• 이메일 (EmailService + event-cancelled.html)

  • sendEventCancellationEmail() 메서드 추가
  • HTML 템플릿: 제목/일시/장소/주최자 연락처/상세설명 포함

• 에러코드 정리

  • CANNOT_DELETE_EVENT_WITH_REGISTRATIONS 에러코드 및 예외 제거

🔎 영향 범위

• 동시성 / 트랜잭션 처리 영향

🔥 관련 이슈

• closes 일정 삭제 정책 수정 #203

[uykhc]

• 이번에는 EventService.delete()와 RegistrationService.deleteInternal()간의 데드락 가능성이 있다고 합니다. 각각 서로의 domain의 락을 먼저 잡기 때문에 발생하는 것으로 보입니다.
• 취소 메일 대상 누락 가능성. 삭제 트랜잭션에서 먼저 일반 조회 getEventByPublicId()를 수행하고, 그 뒤에 락 획득 후 수신자 목록을 일반 조회로 읽습니다.
  MySQL 기본 REPEATABLE READ 가정에서는 락 대기 직전에 커밋된 신청자가 목록 조회에서 빠질 수 있어, 삭제는 되었는데 취소 메일이 누락될 수 있습니다.

그리고 이건 그냥 제 생각인데 동시성 이슈가 발생할 수 있는 부분이 많아 추후에 동시성 관련 통합 테스트를 하나 만들어도 좋을 것 같다고 생각이 듭니다!