올바른 복구 방법 선택
동일한 오류 코드가 두 가지 서로 다른 상황을 나타냅니다. 조치하기 전에retryable을(를) 확인하십시오.
HTTP 상태만으로는 재시도 여부를 판단할 수 없습니다.
다른 입력
요청 처리 중
이 예시에는 HTTP 응답 헤더Retry-After: 1도 포함되어 있습니다.
재시도 식별 정보를 일정하게 유지
멱등성을 문서화한 작업의 경우, 키의 범위는 조직, 서비스 계정, HTTP 메서드, 리소스 경로 및 확인된 API 버전으로 한정됩니다. 이 중 하나라도 변경하면 다른 재시도 식별 정보가 생성되며, 이는 원래 작업을 복구하지 않습니다. 동일한 서비스 계정에서 자격 증명을 교체해도 해당 식별 정보는 변경되지 않지만, 교체된 자격 증명에는 여전히 권한이 있어야 합니다. 시간 초과에서 복구할 때는 원래의 키, 본문, 경로 및 버전을 그대로 유지하십시오. 충돌을 피하기 위해 새 키를 생성하지 마십시오. 원래 쓰기 작업이 이미 성공했을 수 있습니다. 리소스 ID를 알고 있는 경우 해당 리소스를 조회하고, 해당 작업에 문서화된 복구 절차를 따르십시오. 응답 재생이 문서화된 작업에서 완료된 재생 응답에는Idempotent-Replayed: true이(가) 포함됩니다.
Idempotency-Key을(를) 전송한다고 해서 해당 헤더를 지원한다고 참조 문서에 명시된 경우가 아니면 작업이 멱등성을 갖게 되지는 않습니다. 재시도 보호는 해당 작업의 보존 정책에 따라 제한되며, 중복에 대한 영구적인 보장은 아닙니다.
처리가 계속 해결되지 않으면 request_id, UTC 타임스탬프, 메서드, 경로 및 API 버전을 포함하여 Living Security Support에 문의하십시오. API 키, 클라이언트 시크릿 또는 액세스 토큰은 절대 포함하지 마십시오.