#449-1 채팅 검증 개선 및 오류 수정

[chlehdwon]

Summary

It closes #449

Extra info

해당 부분 zod로 validate하도록 변경 완료했습니다.
Front와 연동 결과 잘 작동하는 거 확인하였습니다.

Images or Screenshots

Further Work

• [Front] "정산하기" 버튼 클릭 시, rooms/:id/commitSettlement 호출, "송금하기" 버튼 클릭 시, rooms/:id/commitPayment 호출

[kmc7468]

감사합니다~ 이 PR은 front와 같이 머지되어야 하는거였었나요?

아 그리고 혼동을 막기 위해 채팅이나 DB 같은 부분도 다 payment <-> settlement간 변환이 이루어져도 좋을 것 같습니다. 어떻게 생각하시나요??

[chlehdwon]

네 맞습니다!! 확실하게 맞추려면 그래야할 것 같은데 이하 작업도 여기 브랜치에서 작업할까요?

[kmc7468]

넵 좋습니다! 마이그레이션 스크립트 작성도 필요할 것 같습니당

[chlehdwon]

type 변경 및 migration code도 작성 완료했습니다~! local 상에서는 잘 바뀌는 것 같은데 바뀌는 db가 많은만큼 면밀히 검토하고 반영되면 좋을 것 같습니다!

[withSang]

작업해주셔서 감사드립니다! 좋아 보입니다. 👍
두가지 생각이 들어서 같이 전달드립니다.

• 바뀐 api에 대해 버전 관리가 되면 프론트엔드와 백엔드가 동시에 배포될 필요가 없어지므로, 다운타임 없는 마이그레이션이 더 수월하게 가능해집니다! 동시에 배포해서 양쪽 다 오류가 발생하지 않는다면 문제가 없지만, 보통은 오류 발생 가능성을 염두하여 이런 식으로 점진적으로 변경하시더라고요!
• DB 마이그레이션 시 정합성을 보장하기 위해 백엔드가 반드시 정지되어 있어야 하고, taxi-scheduler의 백업 스크립트가 실행되는 시간도 피해야 합니다. 지금은 저희 mongodb 배포에서 트랜잭션 사용이 불가능하므로, 마이그레이션 코드 단에서 롤백은 불가능합니다. 마이그레이션 전에 반드시 DB를 백업하실 필요가 있어요!

감사합니다!

[chlehdwon]

바쁜 와중에도 리뷰 주셔서 감사합니다 :)

첫 번째 의견 관련하여 저번에도 논의가 있었던 것 같은데 (migration이 필요한 경우 과거/현재 버전 모두 사용 가능하도록 처리 한 후 점진적으로 과거 부분을 없애나간다는 얘기 맞나요?) 이번 경우에는 chat type을 서로 완전히 바꿔야하는지라 현재 시스템 상에서 적용이 어떻게 되어야하는지 애매하긴 하네요...! 말씀하신대로 버전 관리를 도입하여 각 버전에 맞게 백엔드를 관리할 수 있다면 이상적일 것 같습니다.

두 번째 관련해서도 위험성은 인지하고 있어서 서버 정지 후에 진행할 예정입니다. 말씀하신 스크립트나 백업 모두 염두해서 잘 진행하도록 하겠습니다~~!

[kmc7468]

LGTM! 수고하셨습니다~

상님께서 의견주신 것처럼, versioning을 하는 것도 나쁘지 않을 것 같습니다. 제가 염려하고 있는 부분은, 물론 가능성이 아주 낮은 시나리오이긴 하지만, 업데이트 전에 앱을 실행하신 분들이 정산 요청/송금 요청을 날리면 잘못된 Endpoint가 호출되어 꼬일 수도 있을 것 같아서, 이 부분을 방지하기 위해 versioning을 해도 좋을 것 같다고 생각했어요.

논의가 더 필요하기도 하고, 머지 후 즉시 DB 마이그레이션도 진행되어야 해서 Approve는 머지 직전에 남기겠습니다! 코드는 정말 잘 수정해주신 것 같아요. 감사합니다 :)

[chlehdwon]

서버 내리고 migration 진행 할 예정이라 괜찮지 않을까요..? 회의 때 자세한 방법에 대해 논의해봅시다

[kmc7468]

LG M!