[Feat] 알림 테스트 발송 API 추가 - #114
Conversation
프론트 푸시 수신 확인용. 알림 5종 중 4종은 배치(cron)나 이벤트 트리거라
임의 시점에 확인할 수 없어, 로그인 사용자 본인에게 즉시 발송하는 수단을 만든다.
- POST /api/v1/notifications/test { type } — 5종 중 하나를 본인에게 발송
- 실제 발송 경로(NotificationDispatchService.dispatch)를 그대로 사용해
인앱 알림 생성·설정 게이트·FCM payload가 운영과 동일하다(트리거만 수동).
- 템플릿 필수 파라미터가 있는 유형(WARNING·STREAK)은 테스트용 기본값을 채운다.
- 운영에서 아무나 호출하지 못하도록 NOTIFICATION_TEST_ENABLED=true인 환경에서만
동작하고, 그 외에는 403(NOTIFICATION_TEST_DISABLED)을 반환한다.
- 남에게는 보낼 수 없다(대상은 항상 JWT의 본인).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 49 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
Walkthrough인증된 사용자가 알림 유형을 지정해 테스트 알림을 발송할 수 있는 Changes알림 테스트 발송 API
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant AuthenticatedUser
participant NotificationController
participant NotificationService
participant NotificationDispatchService
AuthenticatedUser->>NotificationController: POST /notifications/test
NotificationController->>NotificationController: NOTIFICATION_TEST_ENABLED 확인
NotificationController->>NotificationService: 사용자 ID와 알림 유형 전달
NotificationService->>NotificationDispatchService: 유형별 파라미터로 디스패치
NotificationDispatchService-->>NotificationService: 발송 결과 반환
NotificationService-->>NotificationController: type, sent 반환
NotificationController-->>AuthenticatedUser: 성공 응답
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/notification/notification.service.ts`:
- Around line 43-50: Update sendTestNotification to use the boolean result
returned by dispatch.dispatch as sent instead of always returning true. Ensure
dispatch preserves the contract of returning false when push delivery is skipped
or fails without throwing, and update the related tests to cover both outcomes.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: c582712c-bb2c-4639-90de-8d831c21b630
📒 Files selected for processing (6)
.env.examplesrc/notification/dto/test-notification-request.dto.tssrc/notification/notification-error-code.enum.tssrc/notification/notification.controller.tssrc/notification/notification.service.spec.tssrc/notification/notification.service.ts
CodeRabbit 리뷰 반영: dispatch는 설정이 N이거나 발송이 실패해도 예외 없이
끝나는데, 테스트 API가 무조건 sent:true를 반환해 "보냈다는데 안 온다"는
혼동을 줄 수 있었다. 수신 확인용 API라 결과가 정확해야 한다.
- NotificationDispatchService.dispatch가 DispatchResult
({ notificationId, pushSent })를 반환하도록 계약 변경
· 설정 N으로 건너뜀 / 발송 실패 → pushSent:false
- 테스트 발송 응답을 { type, notificationId, pushSent }로 변경하고
Swagger 설명에 pushSent=false의 의미(설정 N·토큰 없음·발송 실패) 명시
- 반환 계약 검증 테스트 추가
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 participant
📑 이슈 번호
✨️ 작업 내용
알림 5종 중 4종은 배치(cron)나 이벤트 트리거라 임의 시점에 확인할 수 없어,
프론트 푸시 수신 확인용 테스트 발송 수단을 추가합니다.
POST /api/v1/notifications/test { type }— 5종 중 하나를 로그인 본인에게 즉시 발송NotificationDispatchService.dispatch)를 그대로 사용 →인앱 알림 생성·알림 설정 게이트·FCM payload가 운영과 동일(트리거만 수동)
NOTIFICATION_TEST_ENABLED=true인 환경에서만동작하고, 그 외에는 403(
NOTIFICATION_TEST_DISABLED)💭 코멘트
프론트가 초기 요청서 10번 항목("개발 환경 테스트 발송 수단")으로 요청했던 내용입니다.
"운영에서 아무나 호출 가능한 공개 테스트 API는 만들지 않는다"는 조건에 맞춰
① JWT 인증 필수 ② 대상은 항상 본인 ③ env 플래그로 기본 비활성 으로 구성했습니다.
사용하려면 SSM에
/boogle/prod/NOTIFICATION_TEST_ENABLED=true추가 후 재배포가 필요합니다.📸 구현 결과
Summary by CodeRabbit