[IDLE-504] 센터 관리자 인증 승인 및 거절 API #249
Conversation
Walkthrough이 풀 리퀘스트에서는 여러 파일에 대한 변경 사항이 포함되어 있습니다. Changes
Possibly related PRs
Suggested labels
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 12
🧹 Outside diff range and nitpick comments (11)
idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/event/CenterManagerVerificationRejectEvent.kt (1)
6-10: 문서화 및 타입 안전성 개선이 필요합니다.다음 개선 사항들을 고려해 주세요:
- 클래스의 용도와 사용 방법에 대한 KDoc 문서화 추가
- deviceToken을 위한 별도의 value class 정의로 타입 안전성 강화
예시 구현:
+/** + * 센터 관리자 인증 거절 이벤트 + * + * @property notificationId 알림 고유 식별자 + * @property notificationInfo 알림 정보 + * @property deviceToken FCM 디바이스 토큰 + */ data class CenterManagerVerificationRejectEvent( val notificationId: UUID, val notificationInfo: NotificationInfo, - val deviceToken: String, + val deviceToken: DeviceToken, ) +@JvmInline +value class DeviceToken(val value: String)idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/event/CenterManagerVerificationApproveEvent.kt (2)
6-10: 문서화 추가 필요이벤트 클래스의 목적과 각 속성의 역할을 명확히 하기 위해 KDoc 문서화를 추가하는 것이 좋습니다.
다음과 같이 문서화를 추가해보세요:
+/** + * 센터 관리자 인증 승인 이벤트 + * + * @property notificationId 알림 고유 식별자 + * @property notificationInfo 알림 정보 + * @property deviceToken FCM 디바이스 토큰 + */ data class CenterManagerVerificationApproveEvent( val notificationId: UUID, val notificationInfo: NotificationInfo, val deviceToken: String, )
9-9: deviceToken 유효성 검사 추가 고려FCM 디바이스 토큰의 유효성을 보장하기 위해 검증 로직 추가를 고려해보세요.
다음과 같이 검증을 추가할 수 있습니다:
data class CenterManagerVerificationApproveEvent( val notificationId: UUID, val notificationInfo: NotificationInfo, - val deviceToken: String, + val deviceToken: String, +) { + init { + require(deviceToken.isNotBlank()) { "디바이스 토큰은 비어있을 수 없습니다" } + require(deviceToken.length >= 32) { "유효하지 않은 FCM 토큰 형식입니다" } + } )idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/event/CenterManagerVerificationRejectEventPublisher.kt (1)
1-16: 테스트 코드 작성이 필요합니다.이벤트 발행의 정상 동작과 실패 케이스에 대한 단위 테스트가 필요합니다.
테스트 코드 작성을 도와드릴까요? 다음과 같은 테스트 케이스들을 제안드립니다:
- 정상적인 이벤트 발행 테스트
- 이벤트 발행 실패 시 예외 처리 테스트
- 잘못된 이벤트 데이터 처리 테스트
idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/exception/CenterException.kt (1)
22-23: 코드 구현이 잘 되었습니다만, 문서화가 필요합니다.예외 클래스가 적절하게 구현되었습니다. 다만, 이 예외가 발생하는 구체적인 상황에 대한 문서화를 추가하면 좋을 것 같습니다.
다음과 같이 KDoc 문서를 추가하는 것을 제안합니다:
+/** + * 센터 관리자 인증 요청 상태가 'PENDING'이 아닐 때 발생하는 예외 + * + * @throws IsNotPendingException 센터 관리자의 인증 요청 상태가 'PENDING'이 아닌 경우 + */ class IsNotPendingException(message: String = "관리자 인증 요청이 가능한 상태가 아닙니다.") : CenterException(codeNumber = 5, message = message)idle-application/src/main/kotlin/com/swm/idle/application/applys/vo/CarerApplyNotificationInfo.kt (1)
29-29: 불필요한 빈 줄이 있습니다.맵 생성과 반환문 사이의 빈 줄은 제거하는 것이 좋겠습니다.
val notificationDetails = mapOf( "jobPostingId" to jobPostingId, ) - return CarerApplyNotificationInfo(idle-application/src/main/kotlin/com/swm/idle/application/user/center/vo/CenterManagerVerificationApproveNotificationInfo.kt (2)
7-14: 클래스 문서화 개선이 필요합니다.각 프로퍼티의 역할과 사용 목적을 명확히 하기 위해 KDoc 문서화를 추가하는 것이 좋겠습니다.
다음과 같이 문서화를 추가해보세요:
+/** + * 센터 관리자 인증 승인 알림 정보를 담는 데이터 클래스 + * + * @property title 알림 제목 + * @property body 알림 내용 + * @property receiverId 수신자 ID + * @property notificationType 알림 유형 + * @property imageUrl 선택적 이미지 URL + * @property notificationDetails 추가 알림 상세 정보 + */ data class CenterManagerVerificationApproveNotificationInfo(
16-34: 팩토리 메서드에 유효성 검증 로직 추가를 고려해보세요.현재 구현은 기본적인 기능은 잘 수행하고 있지만, 입력값 검증이 없습니다. 특히 title과 body가 비어있지 않은지 확인하는 것이 좋겠습니다.
다음과 같은 개선을 제안합니다:
fun of( title: String, body: String, receiverId: UUID, notificationType: NotificationType, ): CenterManagerVerificationApproveNotificationInfo { + require(title.isNotBlank()) { "제목은 비어있을 수 없습니다" } + require(body.isNotBlank()) { "내용은 비어있을 수 없습니다" } return CenterManagerVerificationApproveNotificationInfo( title, body,idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationRejectEventService.kt (1)
35-51: 코드 스타일 개선을 제안드립니다.몇 가지 작은 개선 사항이 있습니다:
- 변수명이 이전 메서드명을 참조하고 있습니다.
- Kotlin에서는 세미콜론이 불필요합니다.
다음과 같이 수정을 제안드립니다:
private fun createMessage(centerManagerVerificationRejectEvent: CenterManagerVerificationRejectEvent): Message { - val createJobPostingNotification = - createJobPostingNotification(centerManagerVerificationRejectEvent) + val notification = createNotification(centerManagerVerificationRejectEvent) return Message.builder() .setToken(centerManagerVerificationRejectEvent.deviceToken) - .setNotification(createJobPostingNotification) + .setNotification(notification) .putData( "notificationId", centerManagerVerificationRejectEvent.notificationId.toString() ) .putData( "notificationType", centerManagerVerificationRejectEvent.notificationInfo.notificationType.toString() ) - .build(); + .build() }idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationApproveEventService.kt (1)
28-33: 메서드 이름을 용도에 맞게 변경해 주세요.
createJobPostingNotification이라는 메서드 이름이 실제 기능(센터 관리자 인증 알림 생성)과 일치하지 않습니다.다음과 같이 수정을 제안드립니다:
-private fun createJobPostingNotification(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent): Notification { +private fun createVerificationNotification(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent): Notification {관련된 호출부도 함께 수정이 필요합니다:
private fun createMessage(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent): Message { - val createJobPostingNotification = - createJobPostingNotification(centerManagerVerificationApproveEvent) + val notification = createVerificationNotification(centerManagerVerificationApproveEvent)idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/controller/CenterAuthController.kt (1)
47-49: 문서화 추가 제안메서드의 목적과 동작을 명확히 하기 위해 KDoc 문서화를 추가하는 것이 좋겠습니다.
다음과 같은 문서화를 추가해보세요:
+ /** + * 센터 관리자의 인증을 승인합니다. + * + * @param centerManagerId 승인할 센터 관리자의 고유 식별자 + */ override fun approveCenterManagerVerification(centerManagerId: UUID) { centerAuthFacadeService.approveVerification(centerManagerId) }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (17)
idle-application/src/main/kotlin/com/swm/idle/application/applys/vo/CarerApplyNotificationInfo.kt(1 hunks)idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/event/CenterManagerVerificationApproveEventPublisher.kt(1 hunks)idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/event/CenterManagerVerificationRejectEventPublisher.kt(1 hunks)idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/facade/CenterAuthFacadeService.kt(5 hunks)idle-application/src/main/kotlin/com/swm/idle/application/user/center/vo/CenterManagerVerificationApproveNotificationInfo.kt(1 hunks)idle-application/src/main/kotlin/com/swm/idle/application/user/center/vo/CenterManagerVerificationRejectNotificationInfo.kt(1 hunks)idle-domain/src/main/kotlin/com/swm/idle/domain/notification/repository/querydsl/NotificationQueryRepository.kt(2 hunks)idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/entity/jpa/CenterManager.kt(1 hunks)idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/event/CenterManagerVerificationApproveEvent.kt(1 hunks)idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/event/CenterManagerVerificationRejectEvent.kt(1 hunks)idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/exception/CenterException.kt(1 hunks)idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/listener/CenterManagerVerificationApproveEventListener.kt(1 hunks)idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/listener/CenterManagerVerificationRejectEventListener.kt(1 hunks)idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationApproveEventService.kt(1 hunks)idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationRejectEventService.kt(1 hunks)idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/api/CenterAuthApi.kt(2 hunks)idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/controller/CenterAuthController.kt(2 hunks)
🧰 Additional context used
🪛 detekt (1.23.7)
idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationApproveEventService.kt
[warning] 22-22: The caught exception is swallowed. The original exception could be lost.
(detekt.exceptions.SwallowedException)
idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationRejectEventService.kt
[warning] 22-22: The caught exception is swallowed. The original exception could be lost.
(detekt.exceptions.SwallowedException)
🔇 Additional comments (19)
idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/event/CenterManagerVerificationRejectEvent.kt (1)
6-10: 기본 구현이 잘 되어있습니다!
이벤트 클래스의 기본 구조가 명확하고 불변성이 잘 보장되어 있습니다.
idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/event/CenterManagerVerificationRejectEventPublisher.kt (1)
7-10: 클래스 구조가 잘 설계되었습니다!
Spring의 이벤트 발행 패턴을 잘 따르고 있으며, 단일 책임 원칙(SRP)을 잘 준수하고 있습니다. 생성자 주입을 통한 의존성 관리도 적절합니다.
idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/event/CenterManagerVerificationApproveEventPublisher.kt (3)
7-10: 클래스 구조가 잘 설계되었습니다!
이벤트 퍼블리셔 패턴을 잘 구현하였고, 의존성 주입도 적절하게 처리되었습니다. 클래스의 책임이 명확하고 단일 책임 원칙을 잘 따르고 있습니다.
12-14: 이벤트 발행 메서드가 간단명료합니다.
publish 메서드가 불필요한 로직 없이 핵심 기능만 수행하고 있어 유지보수성이 좋습니다. 다만, 예외 처리를 고려해볼 수 있습니다.
이벤트 발행 실패 시의 예외 처리 방식을 확인하기 위해 다음 스크립트를 실행합니다:
✅ Verification successful
Let me analyze the results from the shell scripts. I can see that:
- The application uses Sentry for error tracking and monitoring, as evidenced by the Sentry configuration and dependencies.
- The event publishing mechanism is used in various parts of the application, particularly for notifications (FCM) and other business events.
- The application has proper exception handling patterns in place, with custom exceptions and error handling.
- The event listeners and handlers have try-catch blocks to handle failures gracefully.
Let me generate the final response in Korean:
이벤트 발행 메서드의 예외 처리가 적절히 구현되어 있습니다.
이벤트 발행 실패 시 Sentry를 통해 모니터링되며, 이벤트 리스너에서 적절한 예외 처리가 이루어지고 있습니다. 추가적인 예외 처리는 불필요할 것으로 판단됩니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: 이벤트 리스너에서의 예외 처리 방식 확인
# 이벤트 리스너 클래스 검색
ast-grep --pattern 'class $EVENT_LISTENER {
$$$
@EventListener
$$$
}'
# 예외 처리 관련 코드 검색
rg "try|catch|throw" -A 3
Length of output: 63241
1-16: 이벤트 처리 흐름 검증이 필요합니다.
이벤트 발행자는 잘 구현되었지만, 전체적인 이벤트 처리 흐름을 확인해야 합니다.
다음 스크립트로 이벤트 처리 체인을 검증합니다:
✅ Verification successful
Let me gather more information about the event class and its usage.
이벤트 처리 체인이 올바르게 구현되어 있습니다.
이벤트 처리 흐름이 다음과 같이 완전하게 구현되어 있음을 확인했습니다:
- 도메인 이벤트 정의:
CenterManagerVerificationApproveEvent(UUID, 알림 정보, 디바이스 토큰 포함) - 이벤트 발행:
CenterAuthFacadeService에서CenterManagerVerificationApproveEventPublisher통해 발행 - 이벤트 구독:
CenterManagerVerificationApproveEventListener가@EventListener어노테이션으로 이벤트 수신 - 이벤트 처리:
CenterManagerVerificationApproveEventService를 통한 FCM 처리
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: 이벤트 처리 체인 검증
# 이벤트 클래스 검색
ast-grep --pattern 'class CenterManagerVerificationApproveEvent'
# 이벤트 리스너 검색
ast-grep --pattern 'class $EVENT_LISTENER {
$$$
@EventListener
fun on$_(event: CenterManagerVerificationApproveEvent) {
$$$
}
}'
# 이벤트 발행 호출부 검색
rg "centerManagerVerificationApproveEventPublisher.publish" -A 2
Length of output: 709
Script:
#!/bin/bash
# 이벤트 클래스 정의 확인
rg -t kotlin "class CenterManagerVerificationApproveEvent" -B 2 -A 5
# CenterAuthFacadeService에서 이벤트 발행 컨텍스트 확인
rg -t kotlin "class CenterAuthFacadeService" -B 2 -A 10
# 이벤트 리스너 패턴 검색 (다른 패턴)
ast-grep --pattern '@EventListener
fun $HANDLER(event: CenterManagerVerificationApproveEvent) {
$$$
}'
Length of output: 7462
idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/listener/CenterManagerVerificationRejectEventListener.kt (1)
1-17: FCM 클라이언트 통합 검증이 필요합니다.
이벤트 리스너가 FCM 클라이언트와 올바르게 통합되어 있는지 확인이 필요합니다.
✅ Verification successful
Let me gather more information about the FCM client implementation and service.
Let me check one more aspect to ensure the complete verification.
FCM 클라이언트 통합이 정상적으로 구현되어 있습니다.
FCM 통합이 다음과 같이 올바르게 구현되어 있음을 확인했습니다:
- Firebase 초기화 설정이
FirebaseConfig에서 적절히 처리됨 FcmClient가FirebaseMessaging인스턴스를 통해 메시지 전송을 처리CenterManagerVerificationRejectEventService가 FCM 클라이언트를 주입받아 이벤트 발생 시 알림 메시지를 올바르게 구성하고 전송
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# FCM 클라이언트 구현 및 설정 확인
# FCM 클라이언트 구현 확인
rg -t kotlin "class.*FcmClient"
# FCM 설정 파일 확인
fd -e yml -e properties | xargs rg "fcm|firebase"
# CenterManagerVerificationRejectEventService의 FCM 클라이언트 사용 확인
ast-grep --pattern 'class CenterManagerVerificationRejectEventService {
$$$
send($event: CenterManagerVerificationRejectEvent) {
$$$
}
}'
Length of output: 490
Script:
#!/bin/bash
# FCM 클라이언트 구현 상세 확인
rg -t kotlin -A 10 "class FcmClient"
# CenterManagerVerificationRejectEventService 구현 확인
rg -t kotlin -A 10 "class CenterManagerVerificationRejectEventService"
# FCM 설정 파일 내용 확인
cat idle-infrastructure/fcm/src/main/resources/application-fcm.yml
Length of output: 2863
Script:
#!/bin/bash
# Message 생성 로직 확인
rg -t kotlin -A 10 "createMessage.*CenterManagerVerificationRejectEvent"
# Firebase 초기화 설정 확인
rg -t kotlin "FirebaseApp|FirebaseMessaging.getInstance"
Length of output: 3098
idle-application/src/main/kotlin/com/swm/idle/application/applys/vo/CarerApplyNotificationInfo.kt (2)
Line range hint 15-28: 알림 생성 메서드의 매개변수 추가가 적절해 보입니다.
create 메서드에 jobPostingId 매개변수를 추가한 것이 알림 상세 정보를 더 풍부하게 만들어주어 좋습니다. 이는 센터 관리자 인증 프로세스에서 필요한 정보를 잘 전달할 수 있게 해줄 것입니다.
Line range hint 30-37: 객체 생성 부분이 깔끔하게 구현되었습니다.
명명된 매개변수(named parameters)를 사용하면 더 명확할 수 있지만, 현재 구현도 충분히 읽기 쉽고 이해하기 좋습니다.
idle-application/src/main/kotlin/com/swm/idle/application/user/center/vo/CenterManagerVerificationRejectNotificationInfo.kt (1)
7-14: 데이터 클래스 구현이 적절합니다!
NotificationInfo 인터페이스를 올바르게 구현하였으며, 필수 속성과 선택적 속성의 null 처리가 적절합니다.
idle-application/src/main/kotlin/com/swm/idle/application/user/center/vo/CenterManagerVerificationApproveNotificationInfo.kt (1)
1-6: 패키지 구조와 임포트가 깔끔합니다!
계층형 아키텍처에 맞게 application 레이어에 잘 위치해 있으며, 필요한 임포트들이 잘 정의되어 있습니다.
idle-domain/src/main/kotlin/com/swm/idle/domain/notification/repository/querydsl/NotificationQueryRepository.kt (2)
7-7: NotificationType import 추가가 적절히 이루어졌습니다.
새로운 필터 조건에 필요한 import가 올바르게 추가되었습니다.
41-41: 센터 인증 알림 필터링 로직이 추가되었습니다.
센터 관리자 인증 관련 알림을 제외하는 필터가 적절히 구현되었습니다. 다만 몇 가지 고려사항이 있습니다:
- 페이지네이션에서 특정 알림 타입을 제외하면 페이지 크기가 일관되지 않을 수 있습니다.
- 향후 다른 알림 타입도 제외해야 할 경우를 대비한 확장성 고려가 필요할 수 있습니다.
다음 스크립트로 관련 코드를 확인해보겠습니다:
✅ Verification successful
Let me gather more information about the notification pagination implementation.
Let me check the pagination implementation details one last time.
센터 인증 알림 필터링 로직이 적절히 구현되었습니다.
페이지네이션 구현에서 특정 알림 타입을 제외하는 것은 일반적인 패턴입니다. 현재 구현에서는:
- 센터 인증 알림(CENTER_AUTHENTICATION)만 제외되어 있어 다른 알림들의 일관성은 유지됩니다.
- 코드베이스 전반에 걸쳐 NotificationType enum이 적절히 사용되고 있어, 향후 다른 알림 타입 필터링이 필요할 경우 쉽게 확장할 수 있습니다.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# NotificationType enum 클래스에서 CENTER_AUTHENTICATION 사용 확인
ast-grep --pattern 'enum class NotificationType {
$$$
CENTER_AUTHENTICATION
$$$
}'
# 다른 notification 필터링 패턴 검색
rg "notification\.notificationType\.ne\("
Length of output: 345
Script:
#!/bin/bash
# Check pagination implementation in NotificationQueryRepository
ast-grep --pattern 'fun findAllByMemberId(
$$$
) {
$$$
}'
# Check if there are any other notification type filters
rg "notificationType" -A 3 -B 3
Length of output: 30621
Script:
#!/bin/bash
# Check pagination implementation in NotificationQueryRepository
ast-grep --pattern 'fun findAllByMemberId($$$) {
$$$
.limit($$$)
$$$
}'
# Check if there are any other notification type filters in the repository
ast-grep --pattern '.and(notification.notificationType.ne($$$))'
Length of output: 146
idle-domain/src/main/kotlin/com/swm/idle/domain/user/center/entity/jpa/CenterManager.kt (1)
55-57: 메소드 이름이 더 간결해졌습니다! 👍
updateStatusToApproved에서 approve로의 변경은 명령 패턴에 더 잘 부합하며 가독성이 향상되었습니다.
idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationRejectEventService.kt (1)
1-16: 클래스 구조가 깔끔하고 적절합니다!
의존성 주입과 로깅 설정이 Spring 베스트 프랙티스를 잘 따르고 있습니다.
idle-infrastructure/fcm/src/main/kotlin/com/swm/idle/infrastructure/fcm/users/service/CenterManagerVerificationApproveEventService.kt (1)
10-15: 클래스 구조가 잘 설계되어 있습니다!
Spring의 컴포넌트 관리와 의존성 주입이 적절하게 구현되어 있으며, 로거 초기화도 올바르게 되어 있습니다.
idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/controller/CenterAuthController.kt (2)
18-18: LGTM!
UUID 타입을 사용하기 위한 적절한 import 구문입니다.
51-53: 문서화 추가 및 에러 처리 검증 필요
- KDoc 문서화를 추가하여 메서드의 용도를 명확히 해주세요.
- 존재하지 않는 centerManagerId에 대한 에러 처리가 필요한지 확인이 필요합니다.
문서화 예시:
+ /**
+ * 센터 관리자의 인증을 거절합니다.
+ *
+ * @param centerManagerId 거절할 센터 관리자의 고유 식별자
+ */
override fun rejectCenterManagerVerification(centerManagerId: UUID) {
centerAuthFacadeService.rejectVerification(centerManagerId)
}centerAuthFacadeService의 에러 처리를 확인하기 위해 다음 스크립트를 실행합니다:
✅ Verification successful
문서화 추가 및 에러 처리가 적절히 구현되어 있음을 확인했습니다
CenterAuthFacadeService의 구현을 검토한 결과:
- centerManagerId가 존재하지 않는 경우
centerManagerService.getById()에서 적절한 예외 처리가 이루어집니다. - 검증 상태가 'PENDING'이 아닌 경우
CenterException.IsNotPendingException()을 발생시켜 적절히 처리됩니다. - 거절 처리 후 알림 발송까지 정상적으로 구현되어 있습니다.
다음과 같이 문서화만 추가하면 충분할 것 같습니다:
/**
* 센터 관리자의 인증을 거절합니다.
*
* @param centerManagerId 거절할 센터 관리자의 고유 식별자
* @throws CenterException.IsNotPendingException 센터 관리자의 상태가 PENDING이 아닌 경우
*/🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify error handling in CenterAuthFacadeService
# Search for error handling related to invalid centerManagerId
rg -t kotlin "throw.*NotFoundException.*centerManager"
# Check if there are any custom exceptions defined for invalid verification status
rg -t kotlin "class.*VerificationException"
Length of output: 102
Script:
#!/bin/bash
# Let's try different search patterns to find error handling
# Search for centerManager related exceptions
rg -t kotlin "throw.*center.*manager" -B 2 -A 2
# Search for implementation of rejectVerification
ast-grep --pattern 'fun rejectVerification($$$) {
$$$
}'
# Search for any not found exceptions
rg -t kotlin "class.*NotFoundException" -A 2
# Search for verification status related code
rg -t kotlin "verification.*status|status.*verification" -B 2 -A 2
Length of output: 619
Script:
#!/bin/bash
# Let's search for the implementation and error handling in the facade service
# Search for CenterAuthFacadeService implementation
fd -e kt "CenterAuthFacadeService" --exec cat {}
# Search for any manager related exceptions
fd -e kt "exception" --exec rg -l "manager|Manager" {}
# Search for verification related service implementations
rg -t kotlin "class.*VerificationService" -B 2 -A 5
Length of output: 11540
idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/api/CenterAuthApi.kt (1)
28-28: import 구문이 적절하게 추가되었습니다.
UUID 타입을 사용하기 위한 import 구문이 올바르게 추가되었습니다.
idle-application/src/main/kotlin/com/swm/idle/application/user/center/service/facade/CenterAuthFacadeService.kt (1)
Line range hint 169-178: getCenterManagerForPending 메서드 구현이 적절합니다.
센터 관리자 승인 대기 목록을 올바르게 반환하고 있습니다.
| fun publish(centerManagerVerificationRejectEvent: CenterManagerVerificationRejectEvent) { | ||
| eventPublisher.publishEvent(centerManagerVerificationRejectEvent) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
이벤트 발행 로직 검증이 필요합니다.
이벤트 발행 실패 시의 예외 처리가 누락되어 있습니다. 실패 시나리오에 대한 처리를 추가하는 것이 좋겠습니다.
다음과 같이 예외 처리를 추가하는 것을 제안드립니다:
fun publish(centerManagerVerificationRejectEvent: CenterManagerVerificationRejectEvent) {
- eventPublisher.publishEvent(centerManagerVerificationRejectEvent)
+ try {
+ eventPublisher.publishEvent(centerManagerVerificationRejectEvent)
+ } catch (e: Exception) {
+ throw EventPublishException("센터 관리자 인증 거절 이벤트 발행 실패", e)
+ }
}또한 이벤트 발행 로그를 추가하는 것이 운영 관점에서 도움이 될 것 같습니다:
fun publish(centerManagerVerificationRejectEvent: CenterManagerVerificationRejectEvent) {
+ logger.info("센터 관리자 인증 거절 이벤트 발행: {}", centerManagerVerificationRejectEvent)
eventPublisher.publishEvent(centerManagerVerificationRejectEvent)
}Committable suggestion skipped: line range outside the PR's diff.
| @Component | ||
| class CenterManagerVerificationRejectEventListener( | ||
| private val centerManagerVerificationRejectEventService: CenterManagerVerificationRejectEventService, | ||
| ) { | ||
|
|
||
| @EventListener | ||
| fun handleCenterManagerVerifyRejectEvent(centerManagerVerificationRejectEvent: CenterManagerVerificationRejectEvent) { | ||
| centerManagerVerificationRejectEventService.send(centerManagerVerificationRejectEvent) | ||
| } | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
예외 처리와 로깅을 추가하는 것이 좋겠습니다.
이벤트 리스너의 전반적인 구조는 잘 구현되어 있습니다만, 다음 사항들을 고려해 주시면 좋겠습니다:
- FCM 메시지 전송 실패 시의 예외 처리가 필요합니다.
- 운영 환경에서의 모니터링을 위한 로깅이 필요합니다.
다음과 같이 수정하는 것을 제안드립니다:
@Component
class CenterManagerVerificationRejectEventListener(
private val centerManagerVerificationRejectEventService: CenterManagerVerificationRejectEventService,
+ private val log: Logger = LoggerFactory.getLogger(CenterManagerVerificationRejectEventListener::class.java)
) {
@EventListener
fun handleCenterManagerVerifyRejectEvent(centerManagerVerificationRejectEvent: CenterManagerVerificationRejectEvent) {
+ log.info("센터 관리자 인증 거절 이벤트 수신: {}", centerManagerVerificationRejectEvent.notificationId)
+ try {
centerManagerVerificationRejectEventService.send(centerManagerVerificationRejectEvent)
+ log.info("센터 관리자 인증 거절 알림 전송 완료: {}", centerManagerVerificationRejectEvent.notificationId)
+ } catch (e: Exception) {
+ log.error("센터 관리자 인증 거절 알림 전송 실패: {}", centerManagerVerificationRejectEvent.notificationId, e)
+ throw FcmNotificationException("센터 관리자 인증 거절 알림 전송에 실패했습니다", e)
+ }
}
}Committable suggestion skipped: line range outside the PR's diff.
| @Component | ||
| class CenterManagerVerificationApproveEventListener( | ||
| private val centerManagerVerificationApproveEventService: CenterManagerVerificationApproveEventService, | ||
| ) { | ||
|
|
||
| @EventListener | ||
| fun handleCenterManagerVerifyApproveEvent(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent) { | ||
| centerManagerVerificationApproveEventService.send(centerManagerVerificationApproveEvent) | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
전체적인 구조는 깔끔하나 예외 처리와 로깅이 필요합니다.
이벤트 리스너의 기본 구조는 잘 구현되어 있으나, 다음 사항들을 고려해 주시기 바랍니다:
- FCM 발송 실패 시의 예외 처리가 없습니다.
- 디버깅과 모니터링을 위한 로깅이 필요합니다.
다음과 같이 개선하는 것을 제안드립니다:
@Component
class CenterManagerVerificationApproveEventListener(
private val centerManagerVerificationApproveEventService: CenterManagerVerificationApproveEventService,
+ private val log: org.slf4j.Logger = org.slf4j.LoggerFactory.getLogger(CenterManagerVerificationApproveEventListener::class.java)
) {
@EventListener
fun handleCenterManagerVerifyApproveEvent(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent) {
+ log.info("센터 관리자 인증 승인 이벤트 수신: centerId={}", centerManagerVerificationApproveEvent.centerId)
+ try {
centerManagerVerificationApproveEventService.send(centerManagerVerificationApproveEvent)
+ log.info("센터 관리자 인증 승인 알림 발송 완료: centerId={}", centerManagerVerificationApproveEvent.centerId)
+ } catch (e: Exception) {
+ log.error("센터 관리자 인증 승인 알림 발송 실패: centerId={}", centerManagerVerificationApproveEvent.centerId, e)
+ // TODO: 실패한 알림을 재시도 큐에 넣거나, 모니터링 시스템에 알림을 보내는 것을 고려해주세요
+ }
}
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| @Component | |
| class CenterManagerVerificationApproveEventListener( | |
| private val centerManagerVerificationApproveEventService: CenterManagerVerificationApproveEventService, | |
| ) { | |
| @EventListener | |
| fun handleCenterManagerVerifyApproveEvent(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent) { | |
| centerManagerVerificationApproveEventService.send(centerManagerVerificationApproveEvent) | |
| } | |
| } | |
| @Component | |
| class CenterManagerVerificationApproveEventListener( | |
| private val centerManagerVerificationApproveEventService: CenterManagerVerificationApproveEventService, | |
| private val log: org.slf4j.Logger = org.slf4j.LoggerFactory.getLogger(CenterManagerVerificationApproveEventListener::class.java) | |
| ) { | |
| @EventListener | |
| fun handleCenterManagerVerifyApproveEvent(centerManagerVerificationApproveEvent: CenterManagerVerificationApproveEvent) { | |
| log.info("센터 관리자 인증 승인 이벤트 수신: centerId={}", centerManagerVerificationApproveEvent.centerId) | |
| try { | |
| centerManagerVerificationApproveEventService.send(centerManagerVerificationApproveEvent) | |
| log.info("센터 관리자 인증 승인 알림 발송 완료: centerId={}", centerManagerVerificationApproveEvent.centerId) | |
| } catch (e: Exception) { | |
| log.error("센터 관리자 인증 승인 알림 발송 실패: centerId={}", centerManagerVerificationApproveEvent.centerId, e) | |
| // TODO: 실패한 알림을 재시도 큐에 넣거나, 모니터링 시스템에 알림을 보내는 것을 고려해주세요 | |
| } | |
| } | |
| } |
| fun of( | ||
| title: String, | ||
| body: String, | ||
| receiverId: UUID, | ||
| notificationType: NotificationType, | ||
| ): CenterManagerVerificationApproveNotificationInfo { | ||
| return CenterManagerVerificationApproveNotificationInfo( | ||
| title, | ||
| body, | ||
| receiverId, | ||
| notificationType, | ||
| null, | ||
| null | ||
| ) | ||
| } |
There was a problem hiding this comment.
심각한 오류: 잘못된 타입을 반환하는 팩토리 메서드
of 메서드가 CenterManagerVerificationRejectNotificationInfo 대신 CenterManagerVerificationApproveNotificationInfo를 반환하고 있습니다. 이는 런타임 에러를 발생시킬 수 있는 심각한 문제입니다.
다음과 같이 수정해주세요:
fun of(
title: String,
body: String,
receiverId: UUID,
notificationType: NotificationType,
- ): CenterManagerVerificationApproveNotificationInfo {
- return CenterManagerVerificationApproveNotificationInfo(
+ ): CenterManagerVerificationRejectNotificationInfo {
+ return CenterManagerVerificationRejectNotificationInfo(
title,
body,
receiverId,
notificationType,
null,
null
)
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| fun of( | |
| title: String, | |
| body: String, | |
| receiverId: UUID, | |
| notificationType: NotificationType, | |
| ): CenterManagerVerificationApproveNotificationInfo { | |
| return CenterManagerVerificationApproveNotificationInfo( | |
| title, | |
| body, | |
| receiverId, | |
| notificationType, | |
| null, | |
| null | |
| ) | |
| } | |
| fun of( | |
| title: String, | |
| body: String, | |
| receiverId: UUID, | |
| notificationType: NotificationType, | |
| ): CenterManagerVerificationRejectNotificationInfo { | |
| return CenterManagerVerificationRejectNotificationInfo( | |
| title, | |
| body, | |
| receiverId, | |
| notificationType, | |
| null, | |
| null | |
| ) | |
| } |
| fun approve() { | ||
| this.status = CenterManagerAccountStatus.APPROVED | ||
| } | ||
|
|
||
| fun updateStatusToRejected() { | ||
| fun reject() { | ||
| this.status = CenterManagerAccountStatus.REJECTED | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
상태 전이 검증 로직 추가 필요
현재 구현에서는 어떤 상태에서든 승인/거절이 가능합니다. 안전한 상태 전이를 위해 다음과 같은 검증 로직 추가를 제안드립니다:
fun approve() {
+ require(isPending()) { "승인은 PENDING 상태에서만 가능합니다" }
this.status = CenterManagerAccountStatus.APPROVED
}
fun reject() {
+ require(isPending()) { "거절은 PENDING 상태에서만 가능합니다" }
this.status = CenterManagerAccountStatus.REJECTED
}이렇게 하면:
- PENDING 상태의 요청만 승인/거절 가능
- 잘못된 상태 전이 방지
- 비즈니스 규칙 명확화
Committable suggestion skipped: line range outside the PR's diff.
| try { | ||
| fcmClient.send(message) | ||
| } catch (e: Exception) { | ||
| logger.warn { "FCM 알림 전송에 실패했습니다 : ${message}, 실패한 Event : CenterManagerVerificationApproveEvent" } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
예외 처리를 개선해 주세요.
현재 구현에서 다음 사항들을 고려해 주시면 좋겠습니다:
- 원본 예외를 로그에 포함시켜 디버깅을 용이하게 합니다.
- 실패한 알림에 대한 재시도 메커니즘 도입을 고려해 주세요.
다음과 같이 수정을 제안드립니다:
try {
fcmClient.send(message)
} catch (e: Exception) {
- logger.warn { "FCM 알림 전송에 실패했습니다 : ${message}, 실패한 Event : CenterManagerVerificationApproveEvent" }
+ logger.warn(e) { "FCM 알림 전송에 실패했습니다 : ${message}, 실패한 Event : CenterManagerVerificationApproveEvent" }
+ // TODO: 재시도 로직 구현 고려
}Committable suggestion skipped: line range outside the PR's diff.
🧰 Tools
🪛 detekt (1.23.7)
[warning] 22-22: The caught exception is swallowed. The original exception could be lost.
(detekt.exceptions.SwallowedException)
| @Hidden | ||
| @Operation(summary = "센터 관리자 인증 요청 거절 API") | ||
| @PostMapping("/join/requests/{center-manager-id}/rejection") | ||
| @ResponseStatus(HttpStatus.OK) | ||
| fun rejectCenterManagerVerification(@PathVariable("center-manager-id") centerManagerId: UUID) | ||
|
|
There was a problem hiding this comment.
🛠️ Refactor suggestion
거절 API 엔드포인트에 대한 개선 제안
거절 API도 승인 API와 동일한 맥락에서 다음 개선이 필요합니다:
- 거절 사유를 입력받을 수 있는 요청 본문이 필요할 수 있습니다.
- 실패 시나리오에 대한 응답 정의가 필요합니다.
다음과 같이 개선을 제안드립니다:
@Hidden
@Operation(summary = "센터 관리자 인증 요청 거절 API")
@PostMapping("/join/requests/{center-manager-id}/rejection")
@ResponseStatus(HttpStatus.OK)
+@ApiResponses(
+ value = [
+ ApiResponse(
+ responseCode = "200",
+ description = "거절 성공"
+ ),
+ ApiResponse(
+ responseCode = "404",
+ description = "존재하지 않는 센터 관리자",
+ content = [Content(schema = Schema(implementation = ErrorResponse::class))]
+ ),
+ ApiResponse(
+ responseCode = "400",
+ description = "이미 처리된 요청",
+ content = [Content(schema = Schema(implementation = ErrorResponse::class))]
+ )
+ ]
+)
-fun rejectCenterManagerVerification(@PathVariable("center-manager-id") centerManagerId: UUID)
+fun rejectCenterManagerVerification(
+ @PathVariable("center-manager-id") centerManagerId: UUID,
+ @RequestBody request: CenterManagerRejectionRequest
+)추가로 거절 사유를 위한 요청 클래스도 필요합니다:
data class CenterManagerRejectionRequest(
val reason: String
)
idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/api/CenterAuthApi.kt
Show resolved
Hide resolved
idle-presentation/src/main/kotlin/com/swm/idle/presentation/auth/center/api/CenterAuthApi.kt
Show resolved
Hide resolved
...c/main/kotlin/com/swm/idle/application/user/center/service/facade/CenterAuthFacadeService.kt
Show resolved
Hide resolved
1. 📄 Summary
2. ✏️ Documentation
Goals & Non-Goals
Goals
Methodology & Design(Proposal)
API
API
[센터 관리자 인증 요청 승인 API] POST /api/v1/auth/center/join/requests/{center-manager-id}/approval
POST /api/v1/auth/center/join/requests/{center-manager-id}/approval204 NO CONTENT[센터 관리자 인증 요청 거절 API] POST /api/v1/auth/center/join/requests/{center-manager-id}/rejection
POST /api/v1/auth/center/join/requests/{center-manager-id}/rejection204 NO CONTENTFCM Notification Spec
센터 관리자 인증 요청 승인 API
{ "message" : { "notification" : { "body" : "000 관리자님, 센터 관리자 인증 요청이 최종 승인되었어요! 어서 확인해 보세요!", "title" : "[케어밋] 센터 관리자 인증 요청이 승인되었어요", }, "data" : { "notificationId": "string(uuid)", "notificationType" : "CENTER_AUTHENTICATION", } }센터 관리자 인증 요청 거절 API
{ "message" : { "notification" : { "body" : "000 관리자님, 센터 관리자 인증 요청이 거절되었어요. 문의사항을 통해 연락해 주세요.", "title" : "[케어밋] 센터 관리자 인증 요청이 거절되었어요.", }, "data" : { "notificationId": "string(uuid)", "notificationType" : "CENTER_AUTHENTICATION", } }Summary by CodeRabbit