sync job 수정

[Hank-Choi]

• notification 전부 추가된 후 push 쏘도록 변경
  • 푸시먼저 도착하면 유저입장에서 상세변경사항 안보임
• supervisorScope -> coroutineScope로 변경
  • 노티, 푸시 날릴 때 발생하는 에러도 확인 필요
  • push 전송 시 개별 에러 로깅만 하도록
• push 메시지 보내는 방식 효율화
  • sendMessages 최대한 활용해 token, message로 이루어진 리스트 전달
• pushService, notificationService 분리

[davin111]

notification 전부 추가된 후 push 쏘도록 변경

• 푸시먼저 도착하면 유저입장에서 상세변경사항 안보임

오 이건 섬세한 걸? 좋습니다

[davin111]

일단 일부 noti save 안 되고 push 안 가는 원인이 아직 뭐였는지는 정확히 모르겠지만.

한편으로 나는 supervisorScope 는 유지하고, exception 터졌을 때 모니터링할 방법을 잘 관리해두는 게 낫지 않나 싶긴 해. 예를 들어 log.error 를 찍어도 truffle 로 가고. (근데 슬랙에도 남겼듯, supervisor 썼어도 그 내부 코루틴에서 터진 exception 도 이상적으론 가야하는 거 같아서, 이건 따로 살펴봐야할 듯)

예를 들어 fcm 일시적 에러 같은 거 한 번 났다고 다 터지는 게 좋은가? 싶기도 해서.

[Hank-Choi]

notification 전부 추가된 후 push 쏘도록 변경

이거 원래 이 로직이었긴 해

logger.error 추가해서 날리면 뭐 상관없긴함 근데 일단 이거 머지 후에 나중에 고쳤으면 함

[Hank-Choi]

@davin111 그리고 내가 저번에 말했던 push랑 노티 나누는 거 손봤는데 확인부탁 내가 보기엔 동시에 쓰는 경우가 많지만 분리돼야하는게 맞아보여서 저렇게 나눔

추상화 될 수 없는 모듈인데 추상화 된 느낌이라고 생각

[davin111]

approve 하고서 둘이 나눈 대화 내용

생각해보니 truffle sdk 가 WebFlux WebExceptionHandler 에서 exception 처리 또는 logback integration 으로 log.error 인 경우에 처리해주는 거라, batch 에서는 log.error 로 할 수밖에 없을 것으로 보임.

coroutineScope 로 단순히 해두면 job pod 터지고 나서 즉시 안 보면 이유를 알기 어려울 거 같아서. 에러 발생 시 log.error 찍기로 함.