밖에서 다시 받아 채운 값

연동 결과 식별자를 저장하는 코드에 문제가 있어 몇백 건이 비어 있었다. 상대 응답 형식이 바뀌면서 식별자가 다른 자리로 갔는데 코드가 그것을 못 읽고 널을 저장하고 있었다.

Open Table of contents

등록됐는데 모르는 상태

세어 보니 412건이 등록은 됐는데 식별자가 없었다. 식별자가 없으니 다시 등록하면 중복 등록이 된다.

상대 쪽에는 있고 우리 쪽에만 없는 상태였다. 우리가 잃은 값을 상대가 갖고 있다는 뜻이므로 다시 등록하는 대신 물어보기로 했다.

우리 상품 코드로 상대를 조회하니 식별자가 나왔다. 다만 결과가 하나로 나오는지를 확인해야 했다.

결과가 하나면 복원하고 없으면 등록이 필요한 것으로 표시하며 여럿이면 사람이 봐야 하는 것으로 갈랐다. 복원이 388건이고 없는 것이 18건이며 모호한 것이 6건이었는데 여럿 매칭은 전에 중복 등록된 것이라 자동으로 고르면 틀린 식별자를 넣게 된다.

상대에 없는 18건은 등록이 실패했는데 우리가 성공으로 본 것이었다. 다시 등록하면서 이번에는 응답을 두 형태 다 읽게 하고 그래도 식별자가 없으면 실패로 처리하게 했다.

원인 수정이 여기 있었다. 값이 없을 때 조용히 널을 넣는 대신 예외를 던지게 하면 다음에 형식이 바뀌어도 바로 알 수 있다. 응답 원본도 로그에 남겨서 형식이 바뀌었을 때 확인할 수 있게 했다.

같은 일이 또 생길 수 있으므로 복원을 명령으로 만들어 두고 미리 보기 옵션을 먼저 돌린 뒤 실행했다. 몇 건이 어떻게 되는지를 보고 진행하는 순서다.

등록됐는데 식별자가 빈 건수를 매일 세게 하고 0이 아니면 알리게 했다. 한 번 고치고 끝내지 않고 다시 생기는지를 보는 것이 원인 수정의 검증이다.

식별자는 상대가 갖고 있어서 되찾았지만 우리만 갖고 있던 값은 못 되찾았다. 등록 시각은 상대 응답에 있어서 대략 맞췄고 등록 요청 내용은 어디에도 없었다.

그 뒤로는 요청도 응답과 함께 남기게 했는데 응답만 남기면 무엇을 보냈는지 알 수 없기 때문이다. 무엇이 어디에 있는지를 미리 알아 두면 잃었을 때 되찾을 수 있는지가 바로 갈린다.