워크플로우 및 태스크 작동원리

Workflow 실행과 Task 할당

Workflow 실행은 POST /workflows/{id}/runs로 시작합니다.

1. Client가 등록된 Workflow에 대해 Workflow Run을 요청합니다.
2. Server는 동일 디바이스에 실행 중인 다른 WorkflowRun이 없는지 확인합니다.
3. Server는 WorkflowRun을 생성해 저장하고 첫 Step 실행을 트리거합니다.
4. 현재 Step은 Task로 변환되어 PENDING 상태로 저장됩니다.
5. 이어서 TaskRegisteredEvent가 발행되고, 서버는 다음 두 채널에 상태를 broadcast 합니다.
   • 디바이스용 Moth 채널: TASK_REGISTERED
   • 클라이언트용 이벤트 채널: TASK_REGISTERED
6. Device는 Task를 수신한 뒤 start, complete, reject, abort API로 상태를 보고합니다.
7. Server는 결과에 따라 다음 Step을 시작하거나 WorkflowRun을 완료, 실패, 재시도로 전이합니다.

재시도 정책

• Workflow Run은 실패 즉시 종료되지 않고 현재 Step을 재실행할 수 있습니다.
• 최대 재시도 횟수는 현재 /server-settings에 노출되지 않는 서버 구현 정책입니다.
• abort 시 failPoint가 있으면 재시작 Workflow Run의 첫 Step payload에 반영됩니다.

웹 Client에서 Task 상태 추적

Task 상태 추적 경로는 Device → CoBiz Server → Moth → Client 입니다.

1. Device가 POST /tasks/{id}/start|complete|reject|abort를 호출합니다.
2. Server는 Task 상태를 DB에 저장합니다.
3. 상태 변경마다 Task 도메인 이벤트가 발생합니다.
4. Server는 해당 이벤트를 Moth의 client 채널로 발행합니다.
5. Client는 이벤트를 받은 뒤 Task 또는 Workflow Run 상세를 재조회해 최신 상태를 반영합니다.

Task 상태 전이

• PENDING: 서버가 생성했고 아직 디바이스가 시작하지 않음
• IN_PROGRESS: 디바이스가 시작을 보고함
• COMPLETED: 디바이스가 정상 완료를 보고함
• REJECTED: 디바이스가 작업 수행을 거부함
• ABORTED: 사용자 중단, 디바이스 연결 해제, Workflow 중단 등으로 중단됨

Client가 갱신하는 정보

• 현재 실행 중 Task
• Workflow Run 이력
• 알림 및 toast
• 디바이스 상태 변화에 따른 실행 영향