수락했지만 실행은 못 한다

비동기 작업을 요청하면 수락 응답이 오고 실제 처리는 워커가 한다. 화면에서 버튼을 누르면 수락 응답이 오는데 작업은 뒤에서 실패하고 있었다.

Open Table of contents

조건이 두 곳에 나뉜 구조

요청을 받는 쪽의 검증은 두 조건만 보고 있었다. 워커의 검증에는 그와 다른 조건이 둘 더 있었고 그것들이 거절의 실제 근거였다.

앞쪽이 통과시킨 것을 뒤쪽이 거절하는 사이에 수락 응답은 이미 나간 뒤다. 받는 조건과 처리하는 조건이 갈려 있으면 실패는 항상 뒤로 밀린다.

수락 응답은 받았다는 뜻이지 됐다는 뜻이 아니다. 그런데 화면은 대개 그 구분을 하지 않고 요청되었다는 문구를 띄운다.

사용자는 그 문구를 보고 됐다고 판단하고 그 자리를 떠난다. 실패는 몇 분 뒤 실패 큐에 쌓이고 그 큐는 아무도 보지 않는다.

근본적인 해결은 처리할 수 없는 요청을 애초에 받지 않는 것이었다. 그러려면 버튼을 보여 주는 조건이 워커의 조건과 같아야 한다.

앞쪽의 두 조건이 아니라 네 조건 전부가 노출 조건이 된다. 프론트가 그것을 계산하려면 정보가 응답에 있어야 하므로 조회 응답에 네 필드를 추가했다.

조건을 프론트에 넘길 때 설명 문장이 아니라 표현식으로 적었다. 취소가 아니거나 준비 중일 때라는 문장은 괄호를 어디에 묶느냐에 따라 뜻이 갈린다.

표현식으로 주면 옮겨 적는 것으로 끝나고 해석이 개입하지 않는다. 조건이 세 개를 넘어가면 문장으로 옮기는 순간 정확도가 떨어진다.

여기에 함정이 하나 더 있었는데 능력 정보를 담은 테이블이 공급 쪽 기준으로만 채워져 있었다. 프론트가 들고 있는 것은 판매 쪽 식별자라 그것으로 조회하면 항상 빈 결과가 나온다.

승인과 거절은 판매 쪽 식별자로 맞지만 중계는 공급 쪽 식별자를 써야 했다. 같은 조회 함수인데 동작에 따라 다른 축을 쓰는 것은 문서에 없어서 코드를 봐야 알았고 응답에 공급 쪽 식별자를 새 필드로 넣었다.

같은 우선순위의 연결이 둘일 때 노출 판정과 실제 작업이 다른 것을 고를 수 있다는 문제는 남겼다. 고치려면 데이터 정합성부터 봐야 하므로 별도 사안으로 적어 두고 이번 범위에서 뺐다.