에이전트가 시간 초과되었을 때, 해당 액션은 실제로 발생했을까요?

에이전트가 문서를 게시하기 위해 요청을 제출합니다. 서버는 이를 커밋합니다. 이 응답은 에이전트가 받기 전에 사라집니다.

에이전트는 시간 초과(timeout)를 감지하고 다시 시도합니다.

이제 당신은 두 개의 게시된 문서와 성공적인 복구를 설명하는 로그를 갖게 됩니다.

이는 벤치마크 결과가 아닌 설계 시나리오입니다. 이는 에이전트에게 외부 상태를 변경할 수 있는 도구(tools)를 제공하기 전에 던져야 할 질문을 제기합니다: 액션이 발생했는지 여부를 시스템이 알 수 없을 때, 당신의 시스템은 어떻게 작동합니까?

시간 초과는 호출자(caller)가 적시에 결과를 받지 못했다는 것만을 확립할 뿐입니다. 원격 작업(remote operation)이 실패했다는 것을 확립하지 않습니다. Amazon Builders' Library에서 설명하는 Idempotent API는 이 모호성과 재시도(retry)를 안전하게 만들기 위해 호출자 제공 요청 식별자(caller-provided request identifiers)를 사용하는 방법을 설명합니다.

에이전트 워크플로우의 경우, 저는 그 불확실성을 애플리케이션 계약(application contract)에서 명시적으로 처리할 것입니다.

불확실성에 상태 부여하기

불리언 success 필드는 원격 쓰기(remote write)의 모든 결과를 설명할 수 없습니다. 다음 상태들을 고려해 보세요:

UI는 다음과 같이 표시할 수 있습니다: “요청이 제출되었지만, 완료 여부는 확인되지 않았습니다. 상태를 확인 중입니다.” 이는

애플리케이션 코드에 해당 식별자를 생성하고 영속화하세요. 재시도와 재시작을 거치면서 이를 유지해야 합니다. 만약 대상(destination)이 Idempotency key를 지원한다면, 해당 API의 계약에 따라 동일한 작업에 대해 동일한 키를 전달하세요.

요청 지문(request fingerprint)은 다른 역할을 수행합니다: 변경된 매개변수를 감지하는 것입니다. 서로 다른 대상이나 페이로드로 운영 ID를 재사용하면 충돌을 발생시켜야 합니다. 해시만으로는 의도를 표현할 수 없으며, 두 개의 의도적인 작업이 동일한 페이로드를 가질 수 있습니다.

범위 식별자(Scope identifiers)는 행위자(actor) 또는 테넌트(tenant)에 연결하고, 원자적으로 고유성을 강제하며, 제공업체의 보존 기간(retention window)을 확인하세요. 오래된 키는 대상이 기록을 만료시킨 후 재시도를 보호하는 것을 중단할 수 있습니다.

제안된 작업에 대한 권한 부여를 유지하기

워크플로우가 승인을 필요로 한다면, 무엇이 승인되었는지 기록해야 합니다: 작업(action), 대상(target), 페이로드 버전(payload version) 및 적용 가능한 제한 사항(applicable limits).

정확히 동일한 작업을 재시도하는 경우, 정책이 허용한다면 기록된 권한 부여를 재사용할 수 있습니다. 페이로드를 변경하는 모델은 다른 작업을 제안한 것입니다. 이전 작업에 대한 승인을 조용히 상속해서는 안 됩니다.

실행 시점에도 현재 권한을 다시 확인해야 합니다. 영구적인 승인 기록이 나중에 취소되는 것을 우회해서는 안 됩니다.

로컬 원장(local ledger)은 원격 트랜잭션을 종결할 수 없다

어려운 순서는 다음과 같습니다:

1. 작업을 로컬에서 기록한다.
2. 원격 쓰기(remote write)를 전송한다.
3. 대상이 커밋한다.
...

로컬 트랜잭션은 관련 없는 서비스와 2단계 및 4단계를 원자적으로 만들 수 없습니다.

복구 경로는 대상에 따라 달라집니다:

• 적절한 Idempotency 지원이 있는 경우, 해당 계약 하에서 동일한 작업을 재시도합니다.
• 작업 ID를 통한 권위적인 조회(authoritative lookup)가 가능한 경우, 이를 쿼리하고 결과를 조정합니다(reconcile).
• 둘 다 없는 경우, 알 수 없는 결과(unknown outcome)를 유지하고 다른 중요한 쓰기를 시도하기 전에 조사용으로 라우팅합니다.

빈 검색 결과는 대상이 최종적으로 일관된(eventually consistent) 상태일 경우 결정적이지 않을 수 있습니다. 영구적인 큐(durable queue)가 전송을 개선하지만, 소비자(consumer)는 여전히 중복 시도에 대한 전략이 필요합니다.

불편한 경계 테스트

배포 전에 다음 케이스들을 실행해 보세요:

실질적인 설계 검토 질문은 다음과 같습니다: 만약 이 쓰기(write) 작업이 성공하고 그 응답이 사라진다면, 다음 워커는 무엇을 할지 결정할 증거는 무엇입니까?

만약 답이 단지 “에이전트가 알아서 처리할 것이다”라면, 복구 프로토콜은 여전히 미완성입니다.