개요
네 가지 인터셉션 포인트가 경계를 담당합니다:
크루의 경우 출력 payload는
CrewOutput입니다. 플로우의 경우 최종 플로우
메서드의 결과입니다.
훅 시그니처
return None), 제자리(in-place) 수정,
값을 반환하여 교체, 또는 HookAborted를 발생시켜 중단합니다. 어떤
경계에서든 중단(abort)은 그 사유와 함께 kickoff() 밖으로 전파됩니다.
컨텍스트 스키마
각 포인트는 타입이 지정된 컨텍스트를 받습니다. 모든 컨텍스트는 공통 기본 필드를 공유합니다:ctx.inputs는 원본 입력 dict의 별칭이므로, 어느 이름으로든 제자리
수정은 동일하게 동작합니다. 이전 훅이 새 dict를 반환하여 payload를
교체했다면 ctx.payload만 다시 바인딩됩니다 — 훅이 연쇄될 수 있는 경우
항상 ctx.payload를 읽고 쓰세요.크루 실행 vs. 플로우 실행
경계 훅은 두 런타임 모두에서 발생하며, 크루 실행은 내부적으로 플로우 런타임 위에서 동작합니다. 따라서crew.kickoff() 중에는 전역 경계 훅이 크루
경계(ctx.crew 설정, ctx.flow는 None)와 내부 플로우(ctx.flow
설정, ctx.crew는 None) 모두에서 발생합니다. 런타임으로 구분하세요:
일반적인 사용 사례
시작 시 정책 검사
입력 재작성
INPUT을 사용하고, EXECUTION_START는 허용/거부 게이트로
취급하세요. EXECUTION_START에서의 재작성도 여전히 반영됩니다 — 크루에서는
before_kickoff 콜백에도 전달되고, 플로우에서는 INPUT 재작성과 동일하게
적용됩니다.
출력 정제
OUTPUT은 EXECUTION_END보다 먼저 실행되며, 둘 다 이전 훅에서 (교체되었을
수 있는) payload를 봅니다. 최종적으로 재작성된 값이 kickoff()가 반환하는
값입니다.
실패 관찰
EXECUTION_END는 성공이든 실패든 실행마다 정확히 한 번 발생합니다. 실행이
예외를 던지면 — 태스크 오류, 플로우 메서드 예외, 또는 이전 포인트의
HookAborted — 훅은 ctx.error에 예외가 담긴 status="failed"를 받으며,
원래 예외는 변경 없이 kickoff() 밖으로 전파됩니다:
EXECUTION_START가 디스패치되지 않았다면
EXECUTION_END는 발생하지 않습니다(시작 시점의 중단은 경계가 열리지
않았다는 뜻이므로 짝을 이룰 종료가 없습니다). 또한 실패 경로의
EXECUTION_END 디스패치에서 HookAborted를 발생시키는 것은 무시됩니다 —
더 이상 중단할 것이 없고, 원래 오류가 우선합니다.
순서
크루 실행의 경계 순서는 다음과 같습니다:FlowStartedEvent는 훅이 확정한 입력을 담으며, 경계 훅에서 inputs["id"]를
재작성하면 상태 복원 대상이 바뀝니다. EXECUTION_START에서의 중단은 여전히
FlowStartedEvent 다음에 FlowFailedEvent가 오는 형태로 나타나며, 중단
시점에 그때까지 실행된 훅이 확정한 페이로드와 함께 발생합니다.
같은 포인트의 훅은 등록 순서대로 실행되며, 전역 훅이 먼저, 그다음 크루 범위
훅이 실행됩니다. 텔레메트리(HookDispatchedEvent)는 디스패치마다
발생합니다.
