[트러블슈팅 기록] Sendbird 유저정보 이슈 및 지나간 퍼널이 재등장하는 이슈

김하연·2023년 12월 27일
0

우당탕탕

목록 보기
7/11

회원가입 직후 이용약관 페이지 재등장하는 이슈

원인 파악 과정

회원가입 과정에서 userState가 변경되는 코드에 로그를 찍어서 확인해본 결과

  • 회원가입 시작(약관 동의 페이지) 부터는 userState: sign_up_progressing (프론트 자체에서 상태를 바꿈)
  • 회원가입 마지막 단계인 프로필 사진 업로드 이후 userState: review (프론트 자체에서 상태를 바꿈)
  • 이후 홈탭으로 진입하는 단계에서 userState가 sign_up_progressing 으로 잠시 바꼈다가 review로 다시 돌아옴

→ 홈탭으로 진입하는 순간에 userState를 변경하는 함수가 실행되었다고 생각되어 해당 부분을 추적

원인이 된 코드

  • userState를 서버에서 응답받아 변경하는 코드는 useInitializeRepository.ts 훅 내부에 있음
  • 그렇다면 홈 탭에 진입할 때에 useInitializeRepository.ts 훅을 부르는 것이 무엇인지 확인
  • useRatingCards 훅이 인앱뱃지를 표현하기 위해 badgeContext에서 불리고 있었고, useRatingCards 훅은 enabled 조건에 로그인한 사용자만을 포함하기 위하여 useInitializeRepository 훅 파일에 선언된 useSignIn 훅을 사용중이었다.

결론

signIn 여부를 확인하는 코드만 삭제하여 해결.

useRatingCards가 불리는 부분에서 enabled 조건에 유저 상태가 active review dormant 상태일 경우에만 true 로 설정되어있었던 상황이라 signIn 훅을 사용하여 로그인 상태를 확인하지 않아도 되는 상황이었다.

주요한 실수를 짚어보자면

  • useInitializeRepository라는 훅의 이름부터 앱이 실행되는 시점에 실행되어야 하는 훅인데 해당 훅을 임의로 import 하여 실행 시점이 아닌 이후의 시점에서도 불리게 만든 것
  • signIn상태에 대한 오해. useSignIn 훅에서 확인하는 유저의 로그인 여부는 유저의 프로필을 조회했을 때 user Id가 있느냐 인데 userId는 회원가입 단계에서 번호 인증만 완료해도 생성되고 이용 정지되거나 계정을 삭제한 유저가 삭제되기 전 재로그인을 시도할 때에도 로그인이 완료되면 user Id가 존재하는 상태이다. badge 표현을 위해서라면 로그인 상태를 확인할 것이 아니라 badge 표현에 해당하는 유저 상태를 확인하는 것이 좋았을 것이다.



채팅기능에서 상대 프로필 확인 시 내프로필 등장하는 이슈

원인파악 과정

  • 백엔드에서 가끔 채팅방 나가기 API 요청에 상대 profileId를 넘겨야 하는데 본인의 profileId로 요청이 들어와 에러로그가 찍히고 있다고 전달 → 빈도가 낮았기에 이후 살펴보기로 함
  • QA팀에서 간헐적으로 채팅방 리스트나 채팅방 안에서 상대 프로필을 클릭했을 때 상대 프로필이 아닌 내 프로필이 조회된다는 이슈 제보 → 재현이 어려워 우선순위 낮춰졌음

→ 두 이슈의 연관관계가 있을 것으로 생각되어 채팅방 나가기에 전송하는 profileId, 그리고 상대 프로필을 확인할 때 사용되는 profileId 데이터를 어디서 받아오고 사용하는지를 추적해봄

원인이 된 부분

현재 sendbird 에서 가져오는 데이터들은 sendbird에서 제공하는 각종 메서드들을 맵핑하여 데이터를 가공하고 있는 구조였는데, 두 이슈와 관련된 데이터가 partnerOriginalUser 라는 객체였고 해당 데이터는 get partnerOriginalUser() 라는 메서드에서 생성중이었음

  • get partnerOriginalUser() 의 역할
    • 대화에 참여중인 두 명의 멤버 데이터가 담긴 배열을 find 메서드를 활용하여 순회하고, 순회하면서 나의 userId와 다른 userId를 가진 데이터, 즉 내 데이터가 아닌 상대의 데이터를 찾아서 해당 데이터를 리턴한다.
get partnerOriginalUser(): ChatChannelOriginalUser | undefined {
    if (this.data) {
      const user = this.data.users.find(
        user => user.userId !== this.myOriginalUserId,
      );
      if (user) {
        return {
          profileId: user.id,
          userId: user.userId,
          nickname: user.nickname,
          ...
        };
      }
    }
    return undefined;
  }

위 코드에서 생성된 user라는 상대 유저의 데이터를 로그에 찍어보니, 상대 데이터가 아닌 내 데이터가 출력되고 있음을 확인

const user = this.data.users.find(
  user => {
		// 로그를 찍어 비교문이 잘 작동하는지 확인
		console.debug(user.userId, this.myOriginalUserId, user.userId !== this.myOriginalUserId);
		return user.userId !== this.myOriginalUserId;
	},
);

위와 같이 로그를 찍어서 비교문이 잘 작동하고 있는 것인지 확인을 했는데,

예를 들어 나의 userId인 this.myOriginalUserId 가 100이라면 비교 대상이 되는 user.userId 가 내 정보일 때에도 100으로 찍히는데 user.userId !== this.myOriginalUserId 의 결과는 true 였음

100 !== 100 의 결과가 true 로 찍히는 상황.

혹시해서 typeof this.myOriginalUserId, typeof user.userId 를 다시 로그에 찍어보니 에러가 발생하는 상황에서는 this.myOriginalUserId 의 타입이 string이지만 user.userId 의 타입은 number였다.

상대 데이터가 정상적으로 보여지는 경우에는 두 데이터의 타입이 모두 string으로 동일하였음.

결론

비교문에 데이터들을 string으로 변환하여 형을 일치시키도록 수정

0개의 댓글