[FEAT] 연애관 채팅 프로필 공개 요청 구현#71
Open
Sehi55 wants to merge 18 commits into
Open
Conversation
[Feature] 사용자 사진 관리 기능 구현 및 GCP 배포 전환
[Fix] 배포 시 이미지 환경변수 전달 방식 수정
이미지 계산 방식 개선
[Fix] 배포 단계에서 이미지 주소를 직접 생성
fix: 배포 시 compose 환경변수 로드 보강
fix: compose 실행 시 이미지 변수를 직접 전달
호감/메시지 응답 흐름 및 상대 프로필 과금 로직 개선
관리자 콘솔 및 운영 관리 기능 추가
관리자 회원 사진과 멤버십 표시 수정
운영 환경 SQL 로그 비활성화
수동 배포 실행 버튼 추가
채팅 서비스 구현 및 개선
Walkthrough프로필 사진 요청 생성 시 사전 상태 검증 로직과 새 요청 생성 엔드포인트가 추가되고, 거절 응답 문구가 수정되었습니다. 또한 Notification의 type 필드를 문자열 enum으로 매핑하도록 변경하고, 이를 반영해 DB 컬럼 타입 전환 및 CHECK 제약을 재정의하는 마이그레이션이 추가되었습니다. Changes프로필 사진 요청 흐름
알림 타입 문자열 저장 전환
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant Client
participant PhotoRequestController
participant PhotoRequestService
Client->>PhotoRequestController: POST /request/{chatRoomId}
PhotoRequestController->>PhotoRequestService: createPhotoRequest(chatRoomId, userId)
PhotoRequestService->>PhotoRequestService: getPhotoRequestStatus(roomId, userId)
alt 상태가 READY가 아님
PhotoRequestService-->>PhotoRequestController: IllegalStateException
PhotoRequestController-->>Client: 오류 응답
else 상태가 READY
PhotoRequestService-->>PhotoRequestController: 처리 완료
PhotoRequestController-->>Client: 200 OK ("프로필 사진 공개를 요청했습니다.")
end
Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4✅ Passed checks (4 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
🧹 Nitpick comments (2)
manabom/src/main/java/mannabom_server/manabom/application/matching/service/PhotoRequestService.java (1)
73-92: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win중복 쿼리 및 도달 불가능한 분기 정리 필요
createPhotoRequest에서getPhotoRequestStatus(roomId, userId)를 호출하면 내부적으로findRoomById,validateLoveViewChatRoom,validateActiveMember,photoRequestRepository.findTopByHistoryIdOrderByIdDesc가 다시 실행됩니다. 이는 이미 73-77번 줄에서 수행한 조회/검증과 중복되어 트랜잭션당 불필요한 DB 조회가 두 배로 늘어납니다.또한
getPhotoRequestStatus의 로직(라인 54-68)을 따라가 보면,currentStatus == LoveViewPhotoStatus.READY가 되는 경우는latestOpt가 비어있거나 상태가REJECTED이면서 메시지 수가 10개 이상인 경우뿐입니다. 즉 READY 검증(79-82번 줄)을 통과한 이후에는 88-92번 줄의latestOpt.get().getStatus() != PhotoRequestStatus.REJECTED조건이 항상 거짓이 되어 해당 분기가 도달 불가능한 죽은 코드가 됩니다.
getPhotoRequestStatus가 사용한latestOpt를 반환하거나 재사용할 수 있도록 리팩터링하여 중복 조회를 없애고, 도달 불가능해진 88-92번 줄의 검증을 정리하는 것을 권장합니다.♻️ 리팩터링 방향 예시
- LoveViewPhotoStatus currentStatus = getPhotoRequestStatus(roomId, userId); - if (currentStatus != LoveViewPhotoStatus.READY) { - throw new IllegalStateException("아직 프로필 사진을 요청할 수 있는 상태가 아닙니다."); - } - - LoveViewRecommendHistory loveView = room.getLoveView(); - Long loveViewId = loveView.getId(); - - Optional<LoveViewPhotoRequest> latestOpt = photoRequestRepository.findTopByHistoryIdOrderByIdDesc(loveViewId); - if(latestOpt.isPresent()){ - if(latestOpt.get().getStatus()!=PhotoRequestStatus.REJECTED){ - throw new IllegalStateException("프로필 요청이 중복되었거나 이미 수락된 상태입니다."); - } - } + LoveViewRecommendHistory loveView = room.getLoveView(); + Long loveViewId = loveView.getId(); + Optional<LoveViewPhotoRequest> latestOpt = photoRequestRepository.findTopByHistoryIdOrderByIdDesc(loveViewId); + LoveViewPhotoStatus currentStatus = resolveStatus(room, userId, latestOpt); + if (currentStatus != LoveViewPhotoStatus.READY) { + throw new IllegalStateException("아직 프로필 사진을 요청할 수 있는 상태가 아닙니다."); + }(위와 같이 상태 판별 로직을
latestOpt재사용이 가능한 private 메서드로 추출하고,getPhotoRequestStatus와createPhotoRequest모두에서 활용하도록 리팩터링을 제안합니다.)🤖 Prompt for 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. In `@manabom/src/main/java/mannabom_server/manabom/application/matching/service/PhotoRequestService.java` around lines 73 - 92, `createPhotoRequest` has duplicated room/member/latest-request lookups because `getPhotoRequestStatus(roomId, userId)` re-runs the same queries already done earlier, and the later `latestOpt` status check is dead code once `READY` has been verified. Refactor `PhotoRequestService#createPhotoRequest` and `getPhotoRequestStatus` to share the same fetched `LoveViewPhotoRequest`/status data (for example by extracting a private helper that returns both status and latest request), remove the repeated repository call, and delete the unreachable `latestOpt.get().getStatus() != PhotoRequestStatus.REJECTED` branch.manabom/src/main/resources/db/migration/V18__extend_notification_type_check.sql (1)
1-9: 🗄️ Data Integrity & Integration | 🔵 Trivial | 🏗️ Heavy liftenum 순서 의존성을 줄이세요
Notification.type가 ordinal로 DB에 저장되고 이 CHECK도 그 값에 맞춰져 있습니다. 지금은 맞지만,SseEventName의 순서 변경이나 중간 삽입이 곧바로 스키마 불일치로 이어지므로 고정 코드값이나 STRING 매핑으로 바꾸는 편이 안전합니다.🤖 Prompt for 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. In `@manabom/src/main/resources/db/migration/V18__extend_notification_type_check.sql` around lines 1 - 9, `notification_type_check` and the `Notification.type` mapping currently depend on `SseEventName` ordinals, so a future enum reorder or insertion will break schema consistency. Update the persistence/migration design used by `Notification.type` and the related enum mapping to use stable explicit codes or STRING-based storage instead of ordinal values, and adjust the `notification_type_check` constraint to validate those stable values rather than a positional range.
🤖 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
`@manabom/src/main/resources/db/migration/V18__extend_notification_type_check.sql`:
- Around line 7-9: `notification.type` is still tied to enum ordinal storage,
and the current CHECK constraint only allows a positional range, so enum
reordering or inserts can silently change meaning. Update the `Notification`
mapping to stop using ordinal semantics by switching `type` to
`@Enumerated(EnumType.STRING)` or a fixed `int code` with a converter, then
adjust the `notification_type_check` migration/constraint to match the new
stable representation instead of `0..9`.
---
Nitpick comments:
In
`@manabom/src/main/java/mannabom_server/manabom/application/matching/service/PhotoRequestService.java`:
- Around line 73-92: `createPhotoRequest` has duplicated
room/member/latest-request lookups because `getPhotoRequestStatus(roomId,
userId)` re-runs the same queries already done earlier, and the later
`latestOpt` status check is dead code once `READY` has been verified. Refactor
`PhotoRequestService#createPhotoRequest` and `getPhotoRequestStatus` to share
the same fetched `LoveViewPhotoRequest`/status data (for example by extracting a
private helper that returns both status and latest request), remove the repeated
repository call, and delete the unreachable `latestOpt.get().getStatus() !=
PhotoRequestStatus.REJECTED` branch.
In
`@manabom/src/main/resources/db/migration/V18__extend_notification_type_check.sql`:
- Around line 1-9: `notification_type_check` and the `Notification.type` mapping
currently depend on `SseEventName` ordinals, so a future enum reorder or
insertion will break schema consistency. Update the persistence/migration design
used by `Notification.type` and the related enum mapping to use stable explicit
codes or STRING-based storage instead of ordinal values, and adjust the
`notification_type_check` constraint to validate those stable values rather than
a positional range.
🪄 Autofix (Beta)
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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0166a592-05d5-4144-8f0b-2afc688a5112
📒 Files selected for processing (3)
manabom/src/main/java/mannabom_server/manabom/application/matching/service/PhotoRequestService.javamanabom/src/main/java/mannabom_server/manabom/presentation/matching/controller/PhotoRequestController.javamanabom/src/main/resources/db/migration/V18__extend_notification_type_check.sql
There was a problem hiding this comment.
🧹 Nitpick comments (1)
manabom/src/main/resources/db/migration/V19__change_notification_type_check.sql (1)
1-17: 🚀 Performance & Scalability | 🔵 Trivial대용량 테이블에서
ALTER COLUMN TYPE은 전체 재작성 + 배타적 락을 유발
USING절을 사용한 컬럼 타입 변경은 Postgres에서 테이블 전체를 재작성하며 ACCESS EXCLUSIVE 락을 획득합니다.notification테이블 규모가 커질 경우 배포 시 다운타임을 유발할 수 있으니, 트래픽이 적은 시간대에 실행하거나 테이블 크기를 사전에 확인하는 것을 권장합니다.🤖 Prompt for 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. In `@manabom/src/main/resources/db/migration/V19__change_notification_type_check.sql` around lines 1 - 17, The V19 notification migration changes notification.type with ALTER COLUMN TYPE and a USING CASE, which triggers a full table rewrite and ACCESS EXCLUSIVE lock on the notification table. Update this migration to account for the heavy lock impact by either gating the deployment to a low-traffic maintenance window or adding an explicit pre-check/operational note based on notification table size before running the change. Reference the V19__change_notification_type_check.sql migration and its ALTER TABLE notification block so it’s easy to locate.
🤖 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.
Nitpick comments:
In
`@manabom/src/main/resources/db/migration/V19__change_notification_type_check.sql`:
- Around line 1-17: The V19 notification migration changes notification.type
with ALTER COLUMN TYPE and a USING CASE, which triggers a full table rewrite and
ACCESS EXCLUSIVE lock on the notification table. Update this migration to
account for the heavy lock impact by either gating the deployment to a
low-traffic maintenance window or adding an explicit pre-check/operational note
based on notification table size before running the change. Reference the
V19__change_notification_type_check.sql migration and its ALTER TABLE
notification block so it’s easy to locate.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: df1f8058-4715-4a9a-934a-e246a5f85240
📒 Files selected for processing (2)
manabom/src/main/java/mannabom_server/manabom/domain/notification/entity/Notification.javamanabom/src/main/resources/db/migration/V19__change_notification_type_check.sql
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
변경 사항
주요 구현
POST /api/loveview/profile/request/{chatRoomId}추가READY인지 검증PHOTO_REQUEST_RECEIVED,PHOTO_REQUEST_ACCEPTED,PHOTO_REQUEST_REJECTED이벤트 저장 가능하도록 DB 제약 수정Summary by CodeRabbit
New Features
Bug Fixes