Repository navigation
Messaging and ACK
한국어 | English
AGS의 세션 통신에서 가장 중요한 원칙은 전송, 수신, 처리 확인, 업무 결과를 같은 것으로 취급하지 않는 것입니다.
개념적으로 다음 단계를 구분합니다.
prepared
↓
sent / queued
↓
delivered / claimed
↓
ACK
↓
actual task result
구현 세부 상태 이름은 버전에 따라 달라질 수 있지만, 의미상 이 구분은 유지됩니다.
메시지는 시스템이 발급한 ID로 추적합니다.
전송 결과가 불명확하다고 새 ID의 같은 메시지를 무작정 다시 보내면 중복 업무가 발생할 수 있습니다.
가능하면 같은 message ID의 상태를 먼저 확인합니다.
ACK는 메시지를 처리 대상으로 확인했다는 신호입니다.
ACK가 있다고 해서 다음이 성립하지는 않습니다.
- 요청 업무가 끝났다.
- 검토가 통과했다.
- 사용자가 실행을 승인했다.
- 변경이 안전하다.
- 상대 세션이 결과를 회신했다.
업무 완료는 별도의 결과 메시지와 근거로 확인합니다.
AGS는 메시지 본문과 wake 신호를 분리합니다.
메시지의 실제 내용과 전달 상태는 로컬 메시지 큐에서 관리하고, Codex queue나 Claude Code inbox 같은 host transport는 “새 메시지가 있다”는 신호를 전달하는 가장자리 계층입니다.
따라서 wake 성공만으로 본문 처리 완료를 뜻하지 않습니다.
Session Board는 현재 담당자를 찾기 위한 pull 기반 현황판입니다.
상대 세션이 목록에 보인다는 사실만으로 메시지가 전달되는 것은 아닙니다.
일반적인 흐름은:
Session Board에서 담당자 탐색
↓
PEER message 전송
↓
messageId 상태 추적
↓
ACK
↓
실제 결과 회신
자동 wake 가능 여부는 다음에 영향을 받습니다.
- 수신 host
- 현재 세션 실행 상태
- hook 지원
- wake 설정
- relay/presence 상태
- 현재 generation
- host별 transport
종료된 세션을 단순 idle 상태와 동일하게 취급하면 안 됩니다.
메시지나 ACK가 있다는 이유만으로 peer 작업 완료를 추정하지 않습니다.
AGS의 wait 정책은 실제로 관측 가능한 resume 근거가 있는지 별도로 판단하며, 관측이 불명확한 경우 강한 보장을 만들지 않습니다.
- 기존 message ID 상태를 먼저 조회합니다.
- 본문 전달 상태와 ACK를 구분합니다.
- ACK 이후 실제 결과가 필요한지 확인합니다.
- 불명확한 전송을 새 ID로 반복하기 전에 기존 전송의 상태를 확인합니다.
- update 또는 broker 재시작 뒤에는 구/신 프로세스 혼재 여부를 확인합니다.