openlang

근거가 올 때까지 기다리는 인계 테스트

부분 검토

워커가 실행됐기를 바라며 일정 시간 재우는 대신, 이 작업 인계는 어떻게 테스트할까요?

식별자를 담은 요청 하나를 생각해 봐요. 워커는 버퍼 없는 채널에서 요청을 받고, 그 요청 전용 결과 칸에 식별자를 기록한 뒤 같은 식별자를 담은 확인 응답을 보내요. 송신 완료를 sent, 결과 기록을 observed, 확인 응답 수신을 acknowledged라고 부를게요.

버퍼 없는 채널에서 송신이 끝났다면 그에 대응하는 수신이 일어났다는 건 알 수 있어요. 하지만 워커가 수신 뒤의 문장들을 끝냈다는 뜻은 아니에요. 따라서 sent와 observed의 로그 항목은 어느 쪽이 먼저 나타나도 돼요.

저라면 대응하는 확인 응답을 받은 지점을 테스트 경계로 삼겠어요. 워커가 확인 응답을 보내기 전에 결과를 기록하게 하고, 테스트가 그 응답을 받은 다음 결과를 살펴봐요. 그러면 동기화 관계를 근거로 그 관찰을 설명할 수 있어요. 멈춘 테스트를 끝낼 타임아웃은 두되, 그만큼 기다렸다는 사실로 진행을 입증했다고 하지는 않아요. 여기서 넘겨주는 방식은 간단하게 둬도 되겠어요.

이어지는 대화 3

서로의 근거를 따라
  1. 고유 링크

    이전 호출 코드도 옆에 놓고 같이 보죠. 예전 연산은 작업을 넘겨주고 반환했는데 새 연산은 확인 응답을 받은 뒤 반환한다면, 기존 호출자는 이제 워커의 처리 시간까지 기다릴 수 있어요. 유용한 약속일 수 있지만, 전환 비용도 실제로 생겨요. API에서 두 완료 지점을 모두 드러내 두면 좋겠어요. 기존 호출 코드를 바꾸지 않고도 여전히 컴파일되는지 확인하는 일도 유용해요. 다만 그것만으로 대기 동작이 그대로라고 할 수는 없어요.

  2. 고유 링크

    두 약속을 accepted와 completed로 나누면 어떨까요? 말씀하신 기존 호출자는 계속 접수까지만 기다리고, 결과가 필요한 호출자는 완료를 요청할 수 있겠어요. 이제 곤란한 흐름도 넣어 봐요. 워커가 접수했다고 알린 뒤 완료를 알리기 전에 종료해요. BEAM 기반 설계에서는 격리만으로 복구 정책이 생기지 않고, 링크를 통해 그 실패가 전파될 수 있어요. 호출자가 실패 메시지를 받는지, 재시도하는지, 타임아웃에 도달할 뿐인지도 API에서 밝혀야 해요.