티스토리 뷰

728x90

문제 상황

프론트 개발자님으로부터 매칭 중 문제가 발생했다는 연락을 받았다.

디스코드 메세지
네트워크 탭

- sender(A)는 matching-fail 발생

- receiver(B)는 matching-found-success emit까지 완료

- 그러나 sender에게 matching-found-sender가 전송되지 않음

 

즉, receiver만 매칭 flow가 진행되었고 sender는 중간에 매칭이 진행되지 않는 상황이었다.

문제 확인

곧바로, 해당 시간대의 8080 Java Spring API 서버와 3000 NodeJS socket.io 서버 로그를 확인했다. 다음은 그 중 해당 에러와 관련된 로그만 캡쳐해온 사진이다. 

3000번 소켓(NodeJS) 로그
API 서버(Spring) 로그

 

다음 UML은 각 매칭 flow를 figma에 그린 것이다. 다음 flow는 매칭 성공 flow의 일부분이다. 실시간 매칭 개발을 진행하며 각 상황마다 매칭 flow를 전부 그렸고, 매칭 성공 뿐만 아니라 다양한 실패 flow도 존재한다.

 

이 flow를 따라서 로그를 대조하며 각 단계가 올바르게 수행되고 있는지 확인했다. (눈 빠지는줄..)

 

원인 분석

소켓 서버를 잘 살펴보니까 API 요청 보내는 19번에서 문제가 생기는 것을 발견함.

 

이때, api 서버 로그 살펴보았다.

에러는 refreshToken 관련 트랜잭션 에러만 계속 발생했다.

해당 시간대의 Java 서버 에러

소켓에서 요청된 API 로그를 찾았고, 해당 API에서 이상한 점을 발견했다. 

이상이 있는 API 요청 로그

API 에서 sender matchingUuid랑 receiver matchingUuid가 같게 요청이 되었던 것이다!!!!!!!!!!!!!!!!

이를 확인하고 socket 서버 로그를 다시 확인했다.

로그 분석

 

6번 사용자(A) matchingUuid 는 c71a 8번(B) matchingUuid는 26acdb 이다.

#10) matching-found-receiver에서 senderMatchingInfo에 c71a가 들어가있는 것을 알 수 있다.

#15) 그런데, matching-found-success를 보면 sender가 갑자기 26acdb(B)로 지정되어있다. receiver도 26acdb로 동일!

결과

프론트에서 matching-found-success 보낼 때 자신의 matchingUuid를 senderMatchingUuid로 잘못 넣은 것으로 판단

서버에서는 senderUuid 검증 없이 그대로 받아서

결국 senderSocket = 자기 자신 → 상대방에게 메시지 못 보냄 → matching-found-sender 누락

해결

프론트에서 matching-found-success 이벤트 emit 시, sender Socket matchingUuid를 보내도록 수정

백에서 matching-found-success로 sender matchingUuid를 받을 때 제대로된 sender matchingUuid를 받았는지 확인하는 예외처리가 필요

1. 소켓 서버 : 프론트에서 온 sender Socket matchingUuid가 맞는지 검증

2. API 서버 : found API 발생 시, sender와 receiver matchingUuid가 동일할 경우 예외처리 응답 필요

728x90
250x250
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2025/11   »
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30
글 보관함