feat : 스킬교환 알림 Notification 도메인 연결 및 채팅 Redis Outbox 패턴 적용

[chuuminggg]

🔥ISSUE

feat : 스킬교환 요청 이벤트를 Notification 도메인에 연결 (0cc0de4)

• [Before] 기존 SkillExchange.isRequesterRead / isReceiverRead 플래그만으로 빨간점을 표시하던 방식
• [After] Notification 테이블 + Redis pub/sub 기반 알림으로 연결

refactor : 채팅 Redis 발행을 Transactional Outbox 패턴으로 내재화 (fddb8da)

• [Before] ChatStompController에서 서비스 호출 후 publishToRedis() / publishReadEvent()를 직접 호출
• [After] saveMessage() / markAsRead() 내부에서 afterCommit 콜백으로 처리하도록 변경

📒TODO

1. Notification 테이블 + Redis pub/sub 기반 알림으로 연결.
2. fddb8da : publishToRedis, publishReadEvent → private doPublishToRedis, doPublishReadEvent로 전환
3. fddb8da : afterCommit 내부 예외는 Spring이 억제하므로 throw 대신 로그로 처리
4. fddb8da : Controller는 단순히 서비스만 호출하면 되고, Redis 발행은 서비스가 책임

📋REF

이벤트별 알림 매핑

이벤트	수신자	알림 타입
요청 생성	멘토(receiver)	REQUEST_RECEIVED
요청 생성	멘티(requester)	REQUEST_SENT
수락 / 거절	멘티(requester)	REQUEST_STATUS_CHANGED
취소 by requester	멘토(receiver)	REQUEST_STATUS_CHANGED
취소 by receiver	멘티(requester)	REQUEST_STATUS_CHANGED
만료 (expire)	멘티 + 멘토 양측	REQUEST_STATUS_CHANGED (시스템)

변경 파일

• SkillExchangeRequestProcessor — 요청 생성 시 알림 생성
• SkillExchangeServiceImpl — 수락/거절/취소 시 알림 생성, 보낸/받은 요청 조회 시 Notification 읽음 처리 병행
• SkillExchangeExpireProcessor — 만료 시 양측 시스템 알림 생성
  기존 SkillExchange 플래그 로직(bulkUpdateRequesterReadStatus 등)은 그대로 유지 (하위 호환).

[gemini-code-assist]

Code Review

This pull request implements the Transactional Outbox pattern for chat messages and notifications, ensuring that Redis events are published only after a successful database transaction commit. It also integrates the notification service into the skill exchange workflow, triggering alerts for status changes, sent requests, and received requests. Review feedback focuses on improving the robustness of the transaction synchronization logic by checking for active transactions and preventing potential NullPointerExceptions related to JPA auditing fields that may not be populated before a flush.

[gemini-code-assist]

saved.getCreatedAt()이 null일 경우 NullPointerException이 발생할 위험이 있습니다. JPA Auditing(@CreatedDate) 필드는 트랜잭션 내에서 엔티티가 아직 flush되지 않은 상태라면 채워지지 않을 수 있습니다. 트랜잭션 커밋 전에 해당 값이 필요하다면, 엔티티 저장 후 명시적으로 flush()를 호출하여 필드 생성을 강제하는 것이 좋습니다. 또한 프로젝트의 시간대 정책에 맞게 변환 로직을 점검해 주시기 바랍니다.

chatMessageRepository.save(message);
chatMessageRepository.flush();

References

1. In a transactional context, if a newly created entity's ID or auditing fields are needed for subsequent operations before the transaction commits, explicitly call flush() after saving the entity to force generation and persistence.

[gemini-code-assist]

TransactionSynchronizationManager.registerSynchronization을 호출하기 전에 현재 활성화된 트랜잭션이 있는지 확인하는 것이 안전합니다. NotificationServiceImpl에서 구현된 방식과 마찬가지로 isActualTransactionActive() 체크를 추가하여, 트랜잭션이 없는 환경에서 호출될 경우 IllegalStateException이 발생하는 것을 방지하고 즉시 Redis 발행이 이루어지도록 개선하는 것이 좋습니다.

        if (TransactionSynchronizationManager.isActualTransactionActive()) {
            TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
                @Override
                public void afterCommit() {
                    doPublishToRedis(roomId, savedMessageId, payload);
                }
            });
        } else {
            doPublishToRedis(roomId, savedMessageId, payload);
        }

[gemini-code-assist]

위의 saveMessage 메서드와 동일하게, 트랜잭션 동기화 등록 전에 활성 트랜잭션 여부를 확인하는 로직을 추가하여 코드의 견고함을 높이는 것이 좋습니다.

        if (TransactionSynchronizationManager.isActualTransactionActive()) {
            TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {
                @Override
                public void afterCommit() {
                    doPublishReadEvent(roomId, userId, lastReadId);
                }
            });
        } else {
            doPublishReadEvent(roomId, userId, lastReadId);
        }

[ekdan38]

고생하셨습니다~