CF Workers의 사소한(?) 버그로 인해 8월 4일 privy 세션 인증 경로가 마비 되었다.
privy의 포스트 모텀이 없어서 간단한 추정으로 정리해본 글이다.
8월 4일 코스모에서 트리플에스 오브젝트가 오전 10시에 판매될 예정이었는데, 공지사항으로 외부 솔루션 API 장애로 판매를 연기한다는 공지가 올라왔다.
다소 추상적이지만 이미 해당 공지 포스트 댓글로 누가 cf workers의 status 페이지 스크린샷을 보여주며 cf를 원인으로 지목하고 있었다.
cf status 페이지 들어가보니까 대충 temporal 객체를 워커 런타임에 실수로 노출 시켰는데 그게 0(1970년 1월 1일)을 반환한게 문제였다.
그것 자체로는 당연히 문제가 없었는데 폴리필로 temporal을 쓰던 앱들이 진짜 native temporal이 나오니까 그걸 쓰고 잘못된 시간을 읽으면서 에러가 터진것이다.
근데 그래서 외부 솔루션 api중에 누가 터졌냐? 하면 당연히 앱스트랙트 or Privy를 떠올릴 수 밖에 없다.
모든 로그인이 그러니까 코스모에서 앱스 공식 월렛 계정으로 로그인하지 않고 이메일로 로그인해도 privy를 태우기 때문이다. (폴리곤 시절에도 비슷하게 임베디드 월렛 ramper를 썼다.)
물론 앱스트랙트는 시퀀서도 멀쩡하고 rpc도 멀쩡하고 블록도 잘 생성되고 있었다 아무래도 workers에 의존할 부분이 거의 없을테니까 당연한 일이겠지만 그래도 한번 체크해봤다.
그 후 privy를 보니 `/api/v1/sessions` 경로가 터져있다고 status page에 나온 상태였다.
딱 느낌이 오긴하는게, auth.privy.io는 cloudflare를 쓰고 있기에 인과관계가 있는듯 했다.
다만? 애초에 cf 장애는 7월 30일부터 시작 되었고 8월 3일까지 cf에서도 파악을 못한 상태였다. 아무래도 버그 발생 조건이 약간 까다로운 면이 있어서 그건 놀랄게 아니긴 하지만, 만약 privy가 해당 객체 노출로 터진게 맞다면 조금 타이밍이 안 맞는다.
왜냐면 8월 3일 cf에서 장애를 파악하고 공지한지 8시간 후에 privy가 터지기 시작했고 1시간 10분 정도 후에 privy 자체적으로 해결됐다. 그 후 약 6시간이 지나고 나서야 cf측에서 패치가 나왔다.
그러면 사실상 가설이 크게 하나로 수렴한다: 금요일날 privy 엔지니어들이 temporal을 쓰는 코드를 추가했고 주말동안 워커 배포가 안 이루어지다가 8/3 월요일날 릴리즈 배포를 때렸는데 터진, 그런것.
다만 이러면 대체 왜 안쓰던 temporal을 하필이면 그 시점에 추가해서 배포했냐 그건 의문이긴하다.
물론 workers를 쓴다는 증거도 없고, 외부인이 걔네 펑션 코드를 볼 수 있는것도 아닌지라... 아무래도 외부 관측상으로 어느정도 인과관계 추측이 있다 정도로만 알아두면 될듯하다.