워크플로우 실행 결과와 실패 단계 확인하기
워크플로우 실행과 단계 실행 기록에서 실패 지점과 이미 완료된 외부 효과를 구분하고, 중복 발송이나 중복 결제 없이 원인을 수정해 복구합니다.
이 작업을 마치면기존 성공 작업을 중복 실행하지 않았고 복구 결과가 원래 사건에 연결됩니다.
시작 조건과 입력
중단되거나 실패한 워크플로우 실행 ID와 첫 실패 단계, 연결된 원본 기록 ID를 확인하세요.
이 작업에 사용할 값
entry_url, workflow_run_id, step_run_ids, source_id, cause_record_url, workflow_run_url
커맨드 시퀀스
open "$entry_url" && snapshot -i
click "$workflow_run" && snapshot -i
get text body
open "$cause_record_url" && snapshot -i
get text body
# 외부 수행: 담당자가 원인을 수정한 후 지원되는 복구 경로로 재개합니다. 이미 끝난 발송과 결제를 반복하지 않습니다.
open "$workflow_run_url" && snapshot -i
get text bodyref 대상과 확인할 결과
| # | 커맨드 / ref | 대상과 확인 기준 |
|---|---|---|
| 1 | click $workflow_run | 중단되거나 실패한 워크플로우 실행(workflow_runs) 행 |
| 2 | get text | 실패한 단계 위치, 오류 문구, 이미 성공한 앞 단계와 원본 ID를 읽으세요. |
| 3 | open | 실패 원인에 해당하는 원본 기록(고객, 예약, 계정 등) 보기 |
| 4 | get text | 표시된 오류 원인과 원본 기록의 필드 값을 대조하세요. |
| 5 | 외부 수행 | 담당자가 원인을 수정한 후 지원되는 복구 경로로 재개합니다. 이미 끝난 발송과 결제를 반복하지 않습니다. |
| 6 | open | 복구 후 생성된 워크플로우 실행 기록 |
| 7 | get text | 원래 실행과 복구 시도의 결과를 구분해 읽으세요. |
결과 확인
기존 성공 작업을 중복 실행하지 않았고 복구 결과가 원래 사건에 연결됩니다.
중단 후 다시 시작하기
접수 ID와 원래 요청의 처리 결과를 먼저 확인하세요. 결과를 확인할 수 없다면 같은 요청을 새로 제출하지 않습니다.
워크플로우가 활성 상태로 설정되어 있더라도, 고객 연락처가 비어 있거나 외부 발송 계정의 권한이 만료되면 개별 실행이 실패(failed)할 수 있습니다. 이때 원인을 확인하지 않고 전체 워크플로우를 처음부터 다시 실행하면, 앞 단계에서 이미 성공한 메시지 발송이나 상태 변경이 같은 고객에게 두 번 실행될 위험이 있습니다.
이 문서는 워크플로우 실행에서 실패한 실행과 단계별 결과를 차례대로 읽고, 이미 완료된 작업을 제외한 채 안전하게 원인을 복구하는 절차를 안내합니다.
점검할 실행 상태:
실패(failed)확인할 핵심 기준: 첫 실패 단계 이전의
성공(succeeded) 단계에 외부 발송이나 결제가 포함되어 있는지 여부
실행 기록 찾기
왼쪽 메뉴에서 워크플로우 실행을 엽니다. 목록에서 워크플로우 이름, 상태(대기, 실행 중, 성공, 실패), 시작 시각을 확인하고 점검할 실행 행을 클릭하세요.
| 확인 항목 | 상세 패널에서 볼 내용 | 판단 기준 |
|---|---|---|
실행 상태 (status) | queued, running, succeeded, failed | 전체 단계가 끝까지 완료되었는지, 중간 단계에서 멈췄는지 구분합니다. |
| 출처와 트리거 값 | 실행을 일으킨 원본 사건 데이터 | 어떤 고객, 예약, 구매 기록 때문에 시작된 실행인지 원본 ID를 특정합니다. |
| 시작 및 종료 시각 | 실행이 접수된 시각과 멈춘 시각 | 같은 사건으로 여러 번 실행이 겹쳤는지, 외부 서비스 지연이 있었는지 대조합니다. |
워크플로우 목록에서 상태가 활성이라고 표시되는 것은 앞으로 사건을 감지하겠다는 설정일 뿐, 지난 실행이 성공했다는 뜻이 아닙니다. 실제 성공 여부는 반드시 워크플로우 실행 기록에서 확인하세요.
단계별 입력과 결과
실패한 워크플로우 실행의 상세 패널에서 연결된 단계 실행(step_runs) 목록을 순서(position)대로 확인합니다.
- 첫 실패 단계 이전의 성공 단계 점검: 1번 단계부터 실패 단계 직전까지 이미
succeeded로 끝난 단계가 무엇인지 확인하세요. 만약 앞 단계에서 메시지 발송이나 결제 요청이 이미 성공했다면, 그 작업은 다시 실행해서는 안 됩니다. - 판단(
workflows.decide) 및 건너뜀(skipped) 확인: 단계 상태가skipped라면 오류가 아니라 실행 조건(when)이 맞지 않아 의도적으로 건너뛴 것입니다. 앞선 판단 단계의 출력(values)을 열어 어떤 값으로 분류되었는지 확인하세요. - 실패 원인 분류:
failed단계의 입력(input)과 오류 메시지(error)를 읽고 다음 세 가지 중 어디에 해당하는지 구분합니다.- 원본 데이터 누락: 고객 전화번호 누락, 필수 사용자 필드 비어 있음, 취소된 예약 참조
- 실행 권한 부족: 워크플로우 소유 구성원의 역할에 해당 기능 권한이 없음
- 외부 채널 또는 계정 오류: 발송 계정의 심사 미승인, 수신 거부 고객, 외부 연동 토큰 만료
재실행 조건
오류 원인을 찾았다면 원본 기록($cause_record_url)이나 권한 설정을 먼저 수정한 뒤 복구 범위를 정하세요. 모든 화면에 전체 재실행 버튼이 있다고 가정하거나, 무작정 트리거 사건을 다시 일으키지 마세요.
- 조회나 판단 단계에서 실패한 경우 (외부 부작용 없음): 아직 기록 변경이나 외부 발송이 일어나지 않았으므로, 원본 데이터의 누락된 값을 채우거나 조건을 고친 뒤 다음 스케줄 주기나 지원되는 실행 경로로 재개할 수 있습니다.
- 발송이나 수정 이후 후속 단계에서 실패한 경우 (부분 완료): 이미 완료된 발송을 반복하지 않도록, 실패한 마지막 작업(예: 예약 메모 갱신이나 후속 담당자 요청)만 해당 화면에서 직접 처리하거나 미처리 대상만 고르는 조건으로 실행하세요.
- 반복 실패 시 일시 중지: 외부 계정 장애나 잘못된 필터 조건 때문에 실패가 계속 발생한다면, 먼저 워크플로우 정보 탭에서 상태를
일시 중지(paused)로 바꾼 뒤 조건을 수정하세요.
복구 후 결과
원인을 수정하고 후속 처리를 마쳤다면 다음 세 가지를 대조해 복구를 마무리합니다.
- 원본 기록 상태: 대상 고객이나 예약, 결제 기록이 의도한 최종 상태로 반영되었는지 확인합니다.
- 발송 및 결제 결과: 메시지나 전화 발송이 포함된 작업이라면 발송 기록(
deliveries또는calls)에서 실제 1회만 전달되었고 중복 발송이 없는지 확인합니다. - 실행 이력 보존: 장애 원인을 추적할 수 있도록 원래 실패한 실행 ID와 복구 후 새로 생성된 실행 ID를 함께 확인하고 기록을 임의로 삭제하지 마세요.
결과가 예상과 다를 때
워크플로우 실행은 성공(succeeded)인데 특정 단계가 실행되지 않았습니다
해당 단계 실행(step_runs)의 상태가 skipped인지 확인하세요. 단계에 **실행 조건(when)**이 걸려 있으면 조건을 만족하지 않을 때 오류 없이 건너뛰고 전체 워크플로우 실행은 성공으로 끝납니다. 조건 기준 데이터와 앞선 판단 단계의 출력 값을 대조하세요.
원인을 고쳤는데 다음 주기에도 같은 기록이 계속 실패합니다
반복 조회(heartbeat 또는 cron)가 아직 실패 기록을 계속 선택하고 있는지, 아니면 실제로 수정한 고객이나 예약 행이 다른 중복 행이었는지 원본 ID를 대조하세요.
발송 단계는 성공했는데 고객이 메시지를 받지 못했습니다
단계 실행의 succeeded는 발송 요청 접수가 완료되었다는 뜻입니다. 실제 단말 도달 여부나 수신 거부, 채널 심사 상태는 메시지 전달 결과 확인 또는 해당 발송 기록에서 요청 ID로 확인하세요.