체인을 이긴 관계 테이블

계정이 잘못 연결됐다는 요청을 받고 연결 체인을 따라가 계정을 고쳤다. 조회하면 체인은 새 대상을 가리키는데 인증은 여전히 실패했다.

Open Table of contents

고친 체인과 어긋난 결과

체인을 조인해서 확인하니 새 클라이언트를 정확히 가리키고 있었다. 그런데 전송 로그에는 옛 클라이언트의 자격 증명이 찍히고 있었다.

보이는 연결과 실제로 쓰이는 연결이 다르다는 뜻이다. 그러면 읽는 쪽이 다른 곳을 보고 있다고 봐야 한다.

전송 코드를 따라가니 별도 관계 테이블을 먼저 조회하고 있었다. 거기에 행이 있으면 그것을 쓰고 없을 때만 체인으로 내려가는 구조였다.

관계 테이블에는 옛 클라이언트를 가리키는 행이 남아 있었고 계정을 고쳐도 그 행은 바뀌지 않는다. 내가 정본이라고 생각한 체인이 실제로는 폴백이었다.

이 구조에서는 반대 경우도 성립한다. 관계가 정상이면 체인이 어긋나 있어도 실질 장애가 나지 않는다.

그래서 체인만 보고 정상이라고 말할 수 없고 이상이라고도 말할 수 없다. 점검 순서를 관계 테이블부터 보고 없으면 체인을 보고 둘 다 보정하는 것으로 정했다.

같은 조사에서 클라이언트별 로그인 식별자와 대상 쪽 사용자 식별자가 어긋난 경우도 나왔다. 이 경우 등록은 되는데 조회와 수정이 실패한다.

전부 실패하면 연결을 의심하는데 일부가 되면 연결은 맞다고 보고 다른 원인을 찾게 된다. 부분 실패가 진단이 어려운 것은 되는 것이 있다는 사실이 잘못된 결론을 지지하기 때문이다.

확인은 양방향으로 하기로 했다. 대상의 사용자 식별자가 어느 클라이언트의 것인지 보고 연결된 클라이언트가 그 식별자를 쓰는지도 본다.

한 방향만 보면 연결돼 있다는 것까지만 알 수 있다. 폴백 구조는 결과만 봐서는 어느 경로를 탔는지 감추므로 조건이 참인지 거짓인지가 디버깅의 첫 질문이 된다.