버튼을 누른 뒤 답이 늦으면 다시 누르고 싶어진다. 하지만 자동화에서는 그 클릭이 이미 서버에 전달됐을 수 있다. 북극성을 만들면서 시간 초과를 단순 실패로 처리하는 대신 원래 입력과 기대 결과를 보관하고 읽기로 확인하는 경계를 뒀다.
오류가 난 위치에 따라 다음 행동이 달라진다
버튼을 찾기 전에 실패한 것과 클릭을 실제로 전달한 뒤 결과를 못 읽은 것은 다르다. 앞의 경우에는 새 관찰로 대상을 다시 찾을 수 있다. 뒤의 경우에는 같은 버튼을 다시 누르는 순간 외부 효과가 두 번 생길 수 있다. 오류 코드 하나보다 전달 여부가 복구의 기준이 되는 이유다.
ActionBroker는 단계 시작의 prepared와 실제 전달 앞의 dispatched를 체크포인트로 남긴다. 오류가 나면 전달됐거나 결과 불명 조건이 있는지에 따라 상태를 구분한다. 이 기록은 모든 외부 처리를 정확히 한 번 보장하는 프로토콜이 아니다. 그래도 이후 판단이 막연한 추측보다 원래 입력의 위치에서 시작하도록 만든다.
클릭의 기대 조건을 실행 전에 적는다
clickAndWait와 Enter는 기대할 URL·텍스트·상태를 받는다. 클릭하기 전부터 그 조건이 맞으면 새 행동의 성공을 증명할 수 없으므로 EXPECTATION_ALREADY_TRUE로 거절한다. 그냥 클릭으로 바꾸어 같은 검사를 피하는 경로도 막는다. 결과를 확인하려면 무엇이 달라져야 하는지 먼저 정해야 했다.
URL의 일부가 포함됐다는 느슨한 조건 대신 정확한 URL과 urlRoute를 나눈 비교를 쓴다. 상태 조건도 이름과 역할로 대상이 유일해야 한다. 이 검사가 사이트의 모든 의미를 이해하는 것은 아니지만 에이전트가 편한 조건으로 성공 기준을 바꾸는 일을 줄일 수 있다. 결과를 나중에 끼워 맞추지 않도록 만든 것이다.
결과가 늦으면 원래 조건을 그대로 남긴다
입력이 전달됐는데 제한 시간 안에 기대 조건을 확인하지 못하면 pendingOutcome에 탭과 원래 expect, 단계 기록을 넣는다. OUTCOME_UNKNOWN은 실패했으니 다시 하라는 뜻이 아니라 전달 이후 결과가 아직 확인되지 않았다는 뜻이다. 그 상태에서는 새로운 변경 동작보다 읽기와 결과 확인을 먼저 요구한다.
기존 결과를 지우기 위해 다른 작업을 시작하거나 새 ID를 만들어 같은 제출을 보내는 방식도 피해야 한다. 기록을 다른 이름으로 감추면 외부 서버에 이미 생긴 변화는 사라지지 않는다. 편한 에이전트 도구는 오류를 빨리 없애는 것보다 다음 행동의 근거를 남겨야 한다고 생각했다.
verifyOutcome은 다시 누르는 함수가 아니다
verifyOutcome은 같은 탭의 pendingOutcome을 읽어 원래 기대 조건을 기다린다. 입증되면 원래 단계와 확인 단계에 verified를 남기고 pending을 해제한다. 반환값에도 original_expectation_without_reclick이라는 검증 방식을 적는다. 변경을 다시 전달하지 않고 늦게 나타난 결과를 확인하는 길이다.
확인이 또 실패하면 원래 미확정 상태가 남아야 한다. 새로운 기대 조건으로 교체해 통과시키는 것이 아니다. 여러 단계 flow가 중간에 멈췄다면 이미 끝난 단계와 아직 남은 단계도 고려해야 하며 하나의 늦은 성공이 전체 흐름 완료를 자동으로 증명하지 않는다. 복구의 크기를 원래 행동의 크기에 맞춘다.
공유 대기 모듈에서 시험할 수 있는 부분
공유한 wait 모듈은 기존 실행 ID와 scope를 읽고 완료 조건을 확인한다. 시간 초과와 범위 변경, 중지 뒤 성공 응답, 검증되지 않은 성공을 합성 시험으로 다룬다. 새 클릭이나 제출 함수가 없으므로 대기 오류를 재전송으로 해결하지 않는 책임을 직접 살펴볼 수 있다.
그 모듈이 실제 페이지의 expect를 검사하는 BrowserDriver는 아니다. 실제 사이트 입력과 서버 상태를 대조하는 원래 브라우저 코드의 모든 보호를 대신하지 않는다. 합성 예제에서 확인한 규칙과 원래 제품의 행동 경계, 과거 현장 시험을 서로 다른 근거로 제공한다. 작은 구현을 공개하면서 기능을 넓혀 말하지 않으려 했다.
어디서 멈출지까지가 실행 설계다
회사 업무의 승인·전송·업로드에서도 늦은 응답은 흔히 생길 수 있다. 하지만 이 글은 기존 ERP의 중복 요청 문서를 다시 쓰는 것이 아니라 브라우저의 실제 입력 전달과 문서 관찰 사이 경계를 다룬다. 서버가 제공하는 멱등키가 없는 웹 화면에서는 에이전트가 추측으로 재클릭하지 않는 규칙이 특히 중요했다.
이번 집필에서는 현재 Broker와 page API를 읽었고 운영 브라우저에 오류를 일부러 만들지 않았다. 자동으로 복구하지 못한 상태도 정확히 남기는 것이 목표다. 사용자가 시킨 일을 끝내려는 태도와 증거 없이 같은 효과를 다시 만드는 행동은 구분해야 한다. 나는 그 차이를 코드와 짧은 상태 문구에 함께 남겼다.