Temporal 요구사항

Temporal 요구사항

헌법 조항: Temporal owns execution for proposal-bound work (API queues; Temporal executes). connector: id: temporal · mode: ui_only · endpoint: https://temporal.yamon.io · protected: true · managed_by: argocd

목표

• 모든 동기화/보정 작업의 단일 실행 엔진.

토폴로지 계약

runtime_dependencies.temporal:

temporal:
  enabled: true
  executor_host: 10.10.10.47
  host: temporal-frontend.fractalops.svc.cluster.local
  port: 7233
  namespace: fractalops
  task_queue: fractalops-jobs

service_profiles.temporal(Web UI):

temporal:
  namespace: fractalops
  service: temporal-web
  port: 8080
  public_base_url: https://temporal.yamon.io
  internal_url: http://temporal-web.fractalops.svc.cluster.local:8080

실행 분리 (API queues, Temporal executes)

sequenceDiagram
  autonumber
  participant R as 요청 (Portal / connector)
  participant API as FractalOps API<br/>(validates + queues)
  participant TQ as task_queue<br/>fractalops-jobs
  participant W as Temporal worker
  participant T as 대상 스택 (connector)
  participant AU as audit / reason code

  R->>API: 비-read 작업 요청
  API->>API: 검증 + 기록 (proposal-bound)
  API->>TQ: enqueue (동기 실행 금지)
  W->>TQ: poll
  W->>T: reconcile / delta_cursor / request / repository_dispatch
  alt 성공
    W->>AU: terminal status (completed)
  else 실패
    W->>W: 재시도 + 백오프
    W->>AU: failure + reason code (pending/unresolved)
  end

필수 기능

• reconcile / delta_cursor / request / repository_dispatch 스케줄/워크플로.
• 실패 재시도/백오프 정책 표준화.
• pending/unresolved 보고 구조 표준화.
• API는 검증/기록/큐잉만 하고, 무거운 실행은 Temporal worker가 맡는다. proposal-bound 작업은 큐를 우회할 수 없다.

운영

• 상시 구동(enabled: true, namespace fractalops, task queue fractalops-jobs).
• fractalops namespace retention은 7일이다. Temporal persistence DB는 실행 상태 저장소이지 장기 증거 저장소가 아니다.
• schedule sync를 부팅 절차에 포함한다.
  • 관련 make 타깃: make temporal-worker, make temporal-schedule-sync.
• managed_by: argocd — Temporal 배포는 GitOps(Argo CD)로 관리한다.
• runtime mode가 temporal disabled(예: 임베디드 lab)일 때 settings.temporal_enabled를 확인하고 graceful하게 처리한다.

스토리지 압력

• closed Workflow history는 namespace retention 이후 persistence/visibility store에서 제거되어야 한다. 7일 retention인데 Postgres temporal DB가 빠르게 커지면 open workflow 누적, retry storm, query visibility backfill, archival 미구성을 먼저 확인한다.
• 장기 증거는 Temporal DB가 아니라 Chronicle/evidence store/warehouse projection에 둔다.
• archival을 켜지 않은 상태에서 retention을 늘리는 변경은 공유 CNPG 용량 예산 변경과 같이 리뷰한다.

검증

• job enqueue -> terminal status 도달.
• 실패 케이스가 audit + reason code로 남는지 확인.
• make verify-runtime(API + readiness + Temporal) 통과.