후처리를 어디에 넣나

출고 이후에 값을 읽어 다른 곳에 반영하는 처리를 붙여야 했다. 출고하는 함수의 끝에 넣었더니 읽으려던 값이 비어 있거나 옛 값이었다.

Open Table of contents

한 동작이 두 단계로 나뉜 구조

코드를 따라가니 출고가 한 번에 끝나지 않고 두 단계로 나뉘어 있었다. 운송장을 등록하고 다음 작업을 등록하는 것이 앞 단계이고 출고 완료 처리는 별도 작업에서 돌고 있었다.

내가 넣은 자리는 앞 단계의 끝이라 외부가 아직 최종 처리를 하기 전이었다. 읽으려던 값은 뒤 단계 이후에 생기므로 그 시점에는 존재할 수 없었다.

후처리를 뒤 단계가 성공한 뒤로 옮기니 값이 정상으로 읽혔다. 이 문제의 전부는 출고했다는 말이 어느 시점을 뜻하느냐였다.

함수 이름이 배송을 추가한다는 뜻이라 그것이 출고인 줄 알았는데 실제로는 첫 단계까지였다. 비동기로 다음 단계를 등록하는 구조에서는 함수가 반환됐다고 그 동작이 끝난 것이 아니다.

이 김에 배송 정보를 갱신하는 호출을 경로별로 훑어보니 조건이 제각각이었다. 출고 등록에서는 항상 부르고 출고 취소에서는 옛 데이터일 때만 부르고 일정 연장에서는 부르지 않았다.

그러면 배송 정보가 최신이라는 전제를 쓰는 기능은 어느 경로를 거쳐 왔느냐에 따라 성립하기도 하고 안 하기도 한다. 이 차이는 기능 쪽 코드만 봐서는 드러나지 않는다.

그래서 최신 값을 전제하는 기능을 붙일 때 그 경로가 갱신을 하는지 먼저 확인하기로 했다. 안 하는 경로라면 그 경로에 갱신을 추가하는 안과 후처리에서 직접 최신 값을 조회하는 안이 있다.

앞의 안은 그 경로의 다른 동작에까지 영향을 줄 수 있어서 뒤의 안이 안전했다. 전제를 만드는 쪽을 고치는 것보다 전제를 쓰는 쪽에서 닫는 편이 영향 범위가 좁다.

한 가지는 확인을 못 했는데 외부가 실제로 어느 시점에 값을 확정하는지였다. 우리 쪽 코드는 전부 읽었지만 그쪽 동작은 문서에 없어서 관측으로 추정만 했다.

검증을 시도하다 환경 문제로 실패했고 그 사실도 같이 적었다. 못 한 것을 안 한 것처럼도 한 것처럼도 쓰지 않는 것이 이 기록의 조건이었다.