채팅방에 처음 입장시 읽지 않은 메시지가 정상적으로 출력되지 않았던 문제

정상적인 작동

 

 

총원 3명인 채팅방에 처음 입장했을 때, 읽지 않은 메시지 수가 2로 출력되는 것이 정상이다.
(초기 데이터로 삽입한 메시지들이기 때문에, 아무도 메시지를 읽지 않은 상태)

그런데 실제로는 3명으로 잘못 표시되는 문제가 발생했다.

 

원인 분석

 

채팅방에 새롭게 등록된 멤버의 last_read_message_id가 기본값인 -1로 저장되기 때문이다.

현재 읽지 않은 메시지 수를 구하는 방식은,
각 멤버의 last_read_message_id와 채팅방의 최신 message_id를 비교해서 카운트하는 방식이다.

즉, 처음 채팅방에 들어왔을 때도 이미 읽지 않은 것으로 취급되어 숫자가 줄어들지 않았던 것!

 

 

해결 과정

처음에는 채팅방에 가입 승인이 되었을 때 last_read_message_id 값을 최신 message_id로 설정하는 방식을 생각했다.

 

채팅방에 입장하려면

1. 가입 신청을 하고
2. 방장이 승인을 하면
3. 채팅방 멤버로 등록되는 절차를 거친다.

기존에는  last_read_message_id값을 기본값인 -1로 저장했으나

승인 처리 시 최신 message_id를 last_read_message_id로 넣어주는 로직을 구현했다.

 

그런데 또 다른 문제가 생겼다.

초기 데이터를 삽입하는 순서를 모두 바꿔야 했던 것이다.

멤버 생성 > 채팅방 생성 > 입장, 퇴장, 강퇴 등 기능 테스트 > 채팅 메시지 생성

이런 순서로 데이터를 삽입, 수정 했는데

이런 기존의 순서를 바꿔야 구현한 로직이 초기 데이터에서 제대로 작동했다.

 

순서를 모두 바꾸고 정상적으로 에러 처리를 완료한 것을 보고 팀 프로젝트 백엔드 브랜치에 pr을 보냈다!

 

그런데 프론트엔드에서 훨씬 간단한 해결 방법이 있다는 것을 알게 되었다!!!!

첫 메시지 로드시 updateMessageReadStatus 함수를 실행해서 메시지 읽음 상태를 최신으로 갱신하는데,

갱신과 동시에 fetchMessageCount 함수를 통해 메시지 카운트 갯수를 갱신하면 되는 문제였다

 

백엔드에서 수십분이 걸려서 해결했던 문제를 프론트엔드에서 단 한줄의 코드 추가로 문제를 해결해 버렸다.

 

 

배운 점

백엔드뿐만 아니라 프론트엔드에 대한 이해가 동반되면, 훨씬 유연한 개발이 가능하다!

백엔드에서 복잡한 로직을 고민하는 것도 중요하지만,
프론트엔드에서 해결할 수 있는 부분이 있는지 고려하는 습관이 필요하다는 걸 깨달았다.

서버에서 해결하려고만 하지 않고,

전체적인 시스템 흐름을 이해하는 것이 개발 생산성을 높이는 방법이라는 걸 다시 한 번 느꼈다