refactor: 멘토 및 채팅 관련 API 응답 수정 #537
Conversation
- AS IS: 멘토/멘티 모두 partnerId가 siteUserId - TO BE: 멘티: siteUserId, 멘토: mentorId
whqtker
requested review from
Gyuhyeok99,
Hexeong,
JAEHEE25,
lsy1307,
sukangpunch and
wibaek
as code owners
Walkthrough
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50분
Suggested reviewers
Pre-merge checks and finishing touches✅ Passed checks (4 passed)
✨ Finishing touches
🧪 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: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/main/java/com/example/solidconnection/chat/service/ChatService.java (1)
189-207: WebSocket와 REST 응답의 senderId 의미 불일치 - 통일 필요메시지 조회(GET)는 externalSenderId(멘토면 mentorId, 아니면 siteUserId)를 반환하는 반면, 실시간 WebSocket 송신은
ChatMessageSendResponse.from(chatMessage)로 내부 participantId 기반의 senderId를 보냅니다. 동일 화면에서 과거 메시지와 실시간 메시지의 senderId가 다른 의미를 가지면 클라이언트 파싱이 깨집니다.다음 두 가지 중 하나로 정렬하세요:
- WebSocket도 동일 포맷 사용 (권장)
- 송신 시 externalSenderId를 계산한 후
ChatMessageResponse를 그대로 송신- 영향 범위: 라인 235, 263 및 유사 구간
- 또는 ChatMessageSendResponse에 externalSenderId 추가
ChatMessageSendResponse에 externalSenderId(및 senderType) 필드 추가- from() 메서드에서 조회 로직 추가
클라이언트가 두 타입 모두 일관되게 파싱할 수 있도록 수정해야 합니다.
♻️ Duplicate comments (1)
src/main/java/com/example/solidconnection/chat/service/ChatService.java (1)
139-141: MentorRepository 반환형 수정 필요(중복 지적).
- 이 위치의 .stream()은 Repository가 List를 반환한다고 가정합니다.
- MentorRepository 코멘트에서 지적한 대로 반환형을 List로 바꾸지 않으면 컴파일되지 않습니다.
🧹 Nitpick comments (4)
src/main/java/com/example/solidconnection/chat/domain/ChatMessage.java (1)
31-31: 주석 보강은 적절합니다. 용어 일관성만 유지해 주세요.
- 내부 필드 senderId는 chat_participant의 PK라는 점이 명확해졌습니다.
- 외부 응답에서 멘토/사용자 ID로 매핑되는 값과 혼동을 줄이기 위해, 추후 리팩터링 시 필드명을 senderParticipantId로 바꾸는 것도 고려해 볼 만합니다.
src/main/java/com/example/solidconnection/chat/dto/ChatParticipantResponse.java (1)
4-11: 식별자 혼합 사용에 대한 타입 정보 노출을 권장합니다.
- 현재 partnerId는 멘티면 siteUserId, 멘토면 mentorId입니다.
- 클라이언트 측 혼선을 줄이려면, 다음 중 하나를 추가해 주세요.
- partnerType(MENTOR|MENTEE) 또는 isMentor(boolean) 필드.
- 혹은 명시적 필드 분리(mentorId/siteUserId) 중 하나만 세팅.
가능한 최소 변경 예시(필드 1개 추가):
-public record ChatParticipantResponse( - long partnerId, // 멘티는 siteUserId, 멘토는 mentorId - String nickname, - String profileUrl -) { +public record ChatParticipantResponse( + long partnerId, // 멘티는 siteUserId, 멘토는 mentorId + String partnerType, // "MENTOR" | "MENTEE" + String nickname, + String profileUrl +) { - public static ChatParticipantResponse of(long partnerId, String nickname, String profileUrl) { - return new ChatParticipantResponse(partnerId, nickname, profileUrl); + public static ChatParticipantResponse of(long partnerId, String nickname, String profileUrl) { + // partnerType은 호출부에서 결정되도록 오버로드 추가 또는 기존 호출부 보강 필요 + return new ChatParticipantResponse(partnerId, "MENTEE", nickname, profileUrl); } }클라이언트가 partnerId의 타입이 바뀐 사실을 이미 인지/처리하고 있는지 확인 부탁드립니다.
src/main/java/com/example/solidconnection/chat/service/ChatService.java (1)
190-206: 첨부 조회 N+1 가능성 있습니다.
- ChatAttachment가 LAZY라면 메시지 목록 페이징 시 첨부 조회가 N+1이 됩니다.
- 엔티티 그래프/배치 페치/전용 리포지토리 메서드(fetch join)로 한 번에 가져오는 것을 권장합니다.
예시(리포지토리):
@Query("select distinct m from ChatMessage m left join fetch m.chatAttachments where m.chatRoom.id = :roomId") Slice<ChatMessage> findByRoomIdWithPagingAndAttachments(@Param("roomId") long roomId, Pageable pageable);src/main/java/com/example/solidconnection/mentor/service/MentoringQueryService.java (1)
164-173: toMap 중복 키에 대한 방어를 추가해 주세요.
- 이론상 멘토링:채팅방은 1:1이지만, 데이터 이상 시 Collectors.toMap에서 IllegalStateException이 발생할 수 있습니다.
안전 머지 함수 추가:
- return chatRooms.stream() - .collect(Collectors.toMap(ChatRoom::getMentoringId, ChatRoom::getId)); + return chatRooms.stream() + .collect(Collectors.toMap( + ChatRoom::getMentoringId, + ChatRoom::getId, + (left, right) -> left // 중복 시 최초값 유지 + ));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
src/main/java/com/example/solidconnection/chat/domain/ChatMessage.java(1 hunks)src/main/java/com/example/solidconnection/chat/dto/ChatParticipantResponse.java(1 hunks)src/main/java/com/example/solidconnection/chat/service/ChatService.java(8 hunks)src/main/java/com/example/solidconnection/mentor/dto/MentoringForMentorResponse.java(1 hunks)src/main/java/com/example/solidconnection/mentor/repository/MentorRepository.java(2 hunks)src/main/java/com/example/solidconnection/mentor/service/MentoringQueryService.java(2 hunks)src/test/java/com/example/solidconnection/mentor/service/MentoringQueryServiceTest.java(2 hunks)
🔇 Additional comments (7)
src/main/java/com/example/solidconnection/chat/service/ChatService.java (2)
111-118: 채팅방 목록 파트너 ID 정책을 확인해 주세요.
- 목록 응답(ChatRoomResponse)에서는 partnerId로 siteUserId를 내려주고 있습니다.
- 본 PR 목표는 /rooms/{room-id}/partner만 mentorId로 바꾸는 것으로 이해했으며, 목록 API는 그대로라면 OK입니다.
- 다만 API 스펙 문서에 “목록: siteUserId, 파트너 API: mentorId/ siteUserId 혼합”을 명시해 혼선을 방지해 주세요.
286-301: 검증 결과: 지적된 문제가 없습니다.현재 코드는 이미 올바르게 구현되어 있습니다. 호출 지점(MentoringCommandService.java:54)에서
mentor.getSiteUserId()와mentoring.getMenteeId()를 전달하고 있으며, 두 값 모두ChatParticipant생성자가 기대하는siteUserId입니다.
- mentorId 매개변수:
mentor.getSiteUserId()를 통해 이미 siteUserId를 수신 중입니다.- menteeId 매개변수:
Mentoring.menteeId는long원시형이며, 테스트에서menteeUser.getId()(SiteUser ID)와 비교되고 있어 siteUserId를 저장하고 있습니다.혼동 방지를 위해 매개변수명을
mentorSiteUserId,menteeSiteUserId로 명확히 하는 것은 선택사항의 개선입니다.Likely an incorrect or invalid review comment.
src/main/java/com/example/solidconnection/mentor/service/MentoringQueryService.java (1)
132-141: roomId 누락(null) 가능성에 대한 응답 계약을 확인해 주세요.
- 아직 채팅방이 생성되지 않은 멘토링의 경우 mentoringIdToChatRoomId.get(...)이 null을 반환할 수 있습니다.
- 클라이언트가 null roomId를 허용/처리하는지 스펙 확인이 필요합니다.
src/main/java/com/example/solidconnection/mentor/dto/MentoringForMentorResponse.java (1)
9-9: API 응답 구조 변경이 올바르게 반영되었습니다.변경 사항을 정리하면:
- 필드명 변경:
mentoringId→roomId로 변경하여 API 응답이 실제 채팅방 식별자를 반환하도록 개선- 타입 변경:
long→Long으로 변경하여 채팅방이 없는 경우(대기중/거절된 멘토링)를 null로 표현 가능- 팩토리 메서드: roomId를 외부에서 주입받도록 시그니처 수정 (배치 조회 지원)
이 설계는 승인된 멘토링만 채팅방을 가지는 비즈니스 규칙을 타입 레벨에서 명확히 표현하고 있습니다.
참고: 이는 breaking change이므로, API를 사용하는 클라이언트에서도
mentoringId→roomId필드명 변경에 대응해야 합니다.Also applies to: 17-19
src/test/java/com/example/solidconnection/mentor/service/MentoringQueryServiceTest.java (3)
100-101: 승인된 멘토링에 대한 채팅방 픽스처 추가가 적절합니다.테스트 시나리오를 완성하기 위해 필요한 설정입니다. 승인된 멘토링(
mentoring2)에 대응하는 채팅방을 생성하여, 이후 roomId 검증이 가능하도록 구성했습니다.
106-112: roomId 검증 로직이 비즈니스 규칙을 정확히 반영합니다.변경된 검증 내용:
- PENDING 상태: roomId가 null - 대기중인 멘토링은 채팅방 미생성
- APPROVED 상태: roomId가 chatRoom2.getId() - 승인된 멘토링만 채팅방 존재
- REJECTED 상태: roomId가 null - 거절된 멘토링은 채팅방 불필요
이 assertion은 "승인된 멘토링만 채팅방을 가진다"는 비즈니스 로직을 명확히 검증하고 있습니다.
143-147: 테스트 검증 항목 변경의 의도를 확인해주세요.이 테스트의 주제는 "멘토링 확인 여부 포함"인데, 검증 필드가 변경되었습니다:
- 이전:
mentoringId와isChecked추출- 현재:
nickname과isChecked추출변경 후에도
isChecked값은 올바르게 검증되고 있지만,mentoringId대신nickname으로 각 멘토링을 구분하는 방식으로 개선된 것으로 보입니다.이 변경이 의도된 테스트 개선인지, 아니면 실수로 범위가 확장된 것인지 확인 부탁드립니다. 만약 의도된 개선이라면 문제없으나, roomId 리팩터링과는 직접적인 관련이 없어 보입니다.
src/main/java/com/example/solidconnection/chat/service/ChatService.java
Outdated
Show resolved
Hide resolved
src/main/java/com/example/solidconnection/mentor/repository/MentorRepository.java
Outdated
Show resolved
Hide resolved
|
|
||
| public record ChatParticipantResponse( | ||
| long partnerId, | ||
| long partnerId, // 멘티는 siteUserId, 멘토는 mentorId |
There was a problem hiding this comment.
이거 왜 그냥 멘토멘티 상관없이 siteUserId로 안하고 구분하는건가요??
제가 히스토리가 기억이 안나는 것일 수도 있습니다...
There was a problem hiding this comment.
저도 이 부분에 대해서 암묵적으로 결정했는지, 정하고 넘어갔는지는 기억이 잘 나지 않네요 ...
다만 이 상황에서 partnerId 를 모두 siteUserId 를 넘겨주면 멘토의 경우 추가 DB 접근이 필요하긴 할 거 같습니다
There was a problem hiding this comment.
정해진 게 없다면.... 만욱님과 한 번 이야기해보고 결정하는 건 어떤가요? 프론트에서 헷갈리지 않을까 싶어서요!
There was a problem hiding this comment.
채팅 쪽에서는 하나의 ID(siteUserId)로 통일해 주시는 편이 더 사용성이 좋을 것 같습니다!
라는 쪽으로 결론이 나서 해당 작업만 완료되면 바로 Approve하겠습니다~
src/main/java/com/example/solidconnection/mentor/repository/MentorRepository.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
src/main/java/com/example/solidconnection/mentor/repository/MentorRepository.java (1)
28-29: 메서드 시그니처가 올바르게 수정되었습니다.이전 리뷰에서 제기된 반환 타입 및 파라미터 타입 문제가 모두 해결되었습니다.
다만, 새로 추가된 공개 API 메서드에 대한 단위 테스트가 없습니다. 다음 사항을 검증하는 테스트 추가를 권장합니다:
- 여러 siteUserId로 조회 시 해당하는 모든 Mentor 반환
- 존재하지 않는 siteUserId 조회 시 빈 리스트 반환
- 빈 Set 전달 시 동작
테스트 코드 생성을 원하시면 말씀해 주세요.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/main/java/com/example/solidconnection/chat/service/ChatService.java(8 hunks)src/main/java/com/example/solidconnection/mentor/repository/MentorRepository.java(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (5)
src/main/java/com/example/solidconnection/chat/service/ChatService.java (5)
18-18: 필요한 import가 올바르게 추가되었습니다.추가된 모든 import 문이 코드에서 실제로 사용되며, 멘토 ID 해결 및 스트림 처리 로직에 필요합니다.
Also applies to: 27-28, 33-36
52-52: MentorRepository 의존성 주입이 올바르게 구현되었습니다.표준 Spring 생성자 주입 패턴을 따르며, 기존 코드 스타일과 일관성이 있습니다.
Also applies to: 61-61, 68-68
126-154: 멘토 ID 해결 로직이 올바르게 구현되었습니다.변경 사항이 PR 목표와 정확히 일치합니다:
- 배치 쿼리를 통해 N+1 문제 방지
- NPE 방어 로직 추가 (Line 145-147)
- externalSenderId 해결: 멘토인 경우 mentorId, 아닌 경우 siteUserId 반환
- 주석을 통한 코드 이해도 향상
쿼리 효율성도 적절합니다. 페이지당 3번의 배치 쿼리(메시지, 참가자, 멘토)가 실행되며, 각각 단일 쿼리로 다건 조회를 수행합니다.
167-172: 파트너 ID 해결 로직이 올바르게 구현되었습니다.PR 목표에 맞게 partnerId가 다음과 같이 반환됩니다:
- 파트너가 멘토인 경우: mentorId 반환
- 파트너가 멘티인 경우: siteUserId 반환
Optional 처리 패턴이 적절하며, 주석을 통해 로직이 명확하게 설명되어 있습니다.
192-192: 메서드 시그니처 변경이 올바르게 적용되었습니다.
toChatMessageResponse메서드가externalSenderId파라미터를 받도록 수정되어, 해결된 멘토 ID 또는 사이트 사용자 ID를 응답에 포함할 수 있게 되었습니다.private 메서드이므로 공개 API에 영향을 주지 않으며, 호출부(Line 152)에서 올바르게 전달하고 있습니다.
Also applies to: 206-206
- AS IS: mentorId(mentor) / siteUserId(mentee) - TO BE: siteUserId(all)
- AS IS: mentorId(mentor) / siteUserId(mentee) - TO BE: siteUserId(all)
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
src/main/java/com/example/solidconnection/chat/dto/ChatMessageResponse.java(1 hunks)src/main/java/com/example/solidconnection/chat/dto/ChatParticipantResponse.java(1 hunks)src/main/java/com/example/solidconnection/chat/service/ChatService.java(7 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/main/java/com/example/solidconnection/chat/dto/ChatMessageResponse.java
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
🔇 Additional comments (5)
src/main/java/com/example/solidconnection/chat/dto/ChatParticipantResponse.java (1)
4-4: 명확한 주석 추가, 좋습니다!
partnerId가siteUserId임을 명시하는 주석이 추가되어 코드 가독성이 향상되었습니다. 이전 리뷰 논의에서 채팅 관련 ID를siteUserId로 통일하기로 한 결정과도 일치합니다.src/main/java/com/example/solidconnection/chat/service/ChatService.java (4)
125-126: 메서드 분리로 가독성이 향상되었습니다.채팅 메시지 응답 생성 로직을 헬퍼 메서드로 분리하여
getChatMessages메서드의 복잡도가 감소하고 가독성이 개선되었습니다.
131-139: 배치 조회를 통한 N+1 문제 방지, 잘 구현되었습니다.변경 사항:
- 메시지들의
senderId를 수집하여 한 번에 참여자 정보를 조회합니다.chatParticipantId를 키로 하는Map을 생성하여 효율적인 조회가 가능합니다.- 주석으로 메서드의 목적을 명확히 설명하고 있습니다.
141-155: NPE 방어 로직이 추가되었고, 응답 생성 로직이 명확해졌습니다.변경 사항:
- Line 148-150: 이전 리뷰에서 지적된 NPE 위험에 대한 방어 로직이 추가되어, 참여자를 찾을 수 없는 경우 명확한 예외를 발생시킵니다.
- Line 151:
senderParticipant의siteUserId를externalSenderId로 사용합니다.- Line 152: 추출된
externalSenderId를 사용하여 응답을 생성합니다.확인이 필요한 사항:
현재 구현에서는 모든 발신자에 대해
siteUserId를 반환하고 있습니다. 그런데 PR 목표에는 "senderId가 mentorId 또는 siteUserId가 되도록 수정"이라고 명시되어 있습니다. 이전 리뷰 논의에서 채팅 ID를siteUserId로 통일하기로 결정되었다면 현재 구현이 맞지만, 멘토의 경우mentorId를 반환해야 한다면 추가 매핑 로직이 필요합니다.최종 요구사항을 확인해 주세요.
185-203:toChatMessageResponse메서드 시그니처가 개선되었습니다.변경 사항:
- Line 185: 메서드가 이제
externalSenderId를 파라미터로 받아, 호출자가 발신자 ID 매핑 로직을 제어할 수 있습니다.- Line 199: 전달받은
externalSenderId를 응답에 사용합니다.이 변경으로 발신자 ID 결정 로직이 상위 메서드로 이동하여 책임이 명확해졌습니다.
| import com.example.solidconnection.common.dto.SliceResponse; | ||
| import com.example.solidconnection.common.exception.CustomException; | ||
| import com.example.solidconnection.chat.dto.ChatRoomData; | ||
| import com.example.solidconnection.mentor.repository.MentorRepository; |
There was a problem hiding this comment.
🧩 Analysis chain
사용되지 않는 MentorRepository 의존성이 주입되었습니다.
MentorRepository가 추가되었지만 코드 어디에서도 실제로 사용되지 않고 있습니다. PR 목표에서는 senderId가 멘토의 경우 mentorId, 멘티의 경우 siteUserId를 반환해야 한다고 명시되어 있는데, 현재 구현에서는 모든 경우에 siteUserId만 사용하고 있습니다(Line 151 참조).
다음 중 하나를 확인해 주세요:
- 이전 리뷰 논의에 따라 요구사항이 변경되어 모두
siteUserId를 사용하는 것이 맞다면, 사용하지 않는MentorRepository의존성을 제거해야 합니다. - 멘토의 경우
mentorId를 반환해야 한다면,buildChatMessageResponses메서드에서mentorRepository를 활용하여siteUserId를mentorId로 매핑하는 로직을 추가해야 합니다.
다음 스크립트를 실행하여 MentorRepository가 다른 곳에서 사용되는지 확인해 보세요:
Also applies to: 51-51, 60-60, 67-67
🏁 Script executed:
#!/bin/bash
# ChatService에서 mentorRepository 사용 여부 확인
rg -n "mentorRepository\." --type=java src/main/java/com/example/solidconnection/chat/service/ChatService.javaLength of output: 0
검증을 계속 진행하겠습니다. 현재 ChatService의 구현 내용을 확인하여 멘토레포지토리가 정말 사용되지 않는지, 그리고 요구사항이 실제로 변경되었는지 확인하겠습니다.
🏁 Script executed:
#!/bin/bash
# ChatService 전체 내용 확인 - 특히 buildChatMessageResponses 메서드와 Line 151 주변 코드
fd -n "ChatService.java" --type f | xargs catLength of output: 230
🏁 Script executed:
#!/bin/bash
# Line 51, 60, 67 확인 - mentorRepository 필드 및 생성자
fd -n "ChatService.java" --type f | xargs sed -n '45,75p'Length of output: 230
구문 오류를 수정하겠습니다. ChatService.java 파일을 올바르게 조회하겠습니다.
---
🏁 Script executed:
```shell
#!/bin/bash
# ChatService.java 찾기 및 전체 내용 표시
find . -name "ChatService.java" -type f | head -1 | xargs cat
Length of output: 13813
사용되지 않는 MentorRepository 의존성을 제거하거나 실제로 구현해야 합니다.
전체 코드를 검토한 결과, MentorRepository는 주입(Line 27, 51, 60, 67)만 되어 있고 어디에서도 실제로 사용되지 않고 있습니다.
buildChatMessageResponses 메서드(Line 141-157)에서도 senderParticipant.getSiteUserId()만 사용하고 있습니다.
다음 중 하나를 선택해 주세요:
-
요구사항이 변경되어 모든 경우
siteUserId를 사용하기로 결정되었다면
—MentorRepositoryimport, 필드 선언, 생성자 파라미터 및 할당을 모두 제거하세요. -
멘토의 경우
mentorId를 반환해야 한다면
—buildChatMessageResponses메서드에서senderParticipant또는 역할 정보를 확인하여mentorRepository를 활용해siteUserId를mentorId로 매핑하는 로직을 추가하세요.
🤖 Prompt for AI Agents
In src/main/java/com/example/solidconnection/chat/service/ChatService.java
around lines 27, 51, 60, 67 and in buildChatMessageResponses (lines 141-157):
the MentorRepository is injected but never used; either remove the unused
MentorRepository import, field, constructor parameter and assignment (if
siteUserId is now always used), or implement the mentor-mapping path: add logic
in buildChatMessageResponses to detect mentor participants (via role or
senderParticipant), call mentorRepository to resolve siteUserId to mentorId, and
return mentorId for mentor messages; update imports and constructor to keep
mentorRepository only if you choose the mapping route.
Hexeong
left a comment
Hexeong
left a comment
There was a problem hiding this comment.
제가 pending으로만 올려뒀었네요;; 확인했습니다~
|
|
||
| Map<Long, Long> siteUserIdToMentorId = mentorRepository.findAllBySiteUserIdIn(siteUserIds.stream().toList()).stream() | ||
| .collect(Collectors.toMap(Mentor::getSiteUserId, Mentor::getId)); | ||
|
|
There was a problem hiding this comment.
작성된 의도로 보아 mentorRepository.findAllBySiteUserIdIn() 메서드가 List<Mentor>를 호출하게 하려는 것으로 보입니다! 하지만 MentorRepository에서 정의된 반환타입은 Optional<Mentor>여서 이 부분 한번 확인해주시면 좋을 것 같습니다!
3 participants
관련 이슈
작업 내용
/rooms/{room-id} 에서 응답의 senderId 는 mentorId 가 아니라 chat_participant 테이블의 id 이다. [참고]
senderId는mentorId또는siteUserId가 되어야 합니다.chatParticipantId로 설정되어 있었고(chatMessage의senderId가chatParticipantId임), 이에senderId로chatParticipant를 조회한 후, 다시siteUser를 배치로 찾는 로직을 작성했습니다.{{URL}}/mentor/mentorings?size={{default-size}}&page={{default-page}} 에서 응답으로 mentoringId 말고 roomId 를 포함하도록 [참고]
mapMentoringIdToChatRoomIdWithBatchQuery를 사용하여 구현했습니다.rooms/{room-id}/partner 응답의 partnerId 가 siteUserId 가 아니라 mentorId 가 되도록 [참고]
응답에서 사용자 관련 id는
siteUserId로 통일한다. [참고]특이 사항
리뷰 요구사항 (선택)