내가 만든 버그

1. 자동으로 연결이 복구되면 기존에 스케줄링되어 있던 태스크들 역시 자동으로 새로운 채널에 등록해 주는 로직이 있었다. 이 로직이 수동 연결 구현에도 공통으로 사용되어 수동 태스크 스케줄링과 중복으로 수행되는 버그가 있었다.

2. 태스크들을 스케줄링할 때 추후 취소 동작을 위한 객체를 따로 저장해 두고 있었다. 연결 복구 후 태스크들을 다시 스케줄링하며 취소 객체는 이전 것을 바라보고 있는 버그가 있었다.

배운 것

위 버그로 태스크가 누적 스케줄링되어 전송 메시지 역시 큐에 누적해서 쌓이게 되었다. 그래서 Close 를 해도 Close 동작이 길게는 1분 후에 수행되었다. Close 작업 역시 작업 큐에 쌓였다가 먼저 쌓여있던 쓰기 작업이 모두 완료되면 수행되는구나.

돌아보며

프레임워크에 의존하다보니 동작을 커스터마이징하기가 어렵다. 위 같은 상황이면 Close 작업을 우선순위 큐 컨셉으로 앞으로 넣어버리고, 뒤의 작업은 모두 삭제해 버리면 될 것 같은데 내 맘대로 할 수가 없다. 엄청 답답하단 느낌이 들지만 일단 적응하는 걸로.

다시 돌아보니

적고 보니 파이프라인 사이사이가 큐로 고정되어 있는게 문제가 아니라 메시지가 중복 발행되고 있는게 문제 였다. 프레임워크는 문제가 없고 내 느낌이 사실에 근거한게 아니었다. 글쓰기는 역시 메타인지를 도와준다.

여러 가지로 어려웠지만 문제를 기회로 바라보게 됩니다.