Выбор правильного способа восстановления
Один и тот же код ошибки описывает две разные ситуации. Прежде чем предпринимать действия, проверьтеretryable: по одному лишь HTTP-статусу невозможно определить, следует ли повторять запрос.
Другие входные данные
Запрос все еще обрабатывается
В этом примере также присутствует заголовок HTTP-ответаRetry-After: 1.
Сохранение неизменной идентичности повторного запроса
Для операций, в документации к которым описана идемпотентность, ключ привязан к организации, сервисной учетной записи, HTTP-методу, пути ресурса и определенной версии API. Изменение любого из этих параметров создает другую идентичность повторного запроса и не позволяет восстановить исходную операцию. Смена учетных данных в рамках той же сервисной учетной записи не меняет эту идентичность, однако у новых учетных данных по-прежнему должны быть необходимые разрешения. При восстановлении после тайм-аута сохраняйте исходные ключ, тело запроса, путь и версию. Не создавайте новый ключ только для того, чтобы обойти конфликт: исходная операция записи могла уже завершиться успешно. Если идентификатор ресурса известен, получите ресурс и воспользуйтесь описанной для этой операции процедурой восстановления. Завершенный повторный ответ содержитIdempotent-Replayed: true, если для операции описано воспроизведение ответа.
Отправка Idempotency-Key не делает операцию идемпотентной, если в справочнике по этой операции явно не указана поддержка данного заголовка. Защита от повторов ограничена политикой хранения данных для операции и не является постоянной гарантией отсутствия дубликатов.
Если проблема с обработкой не устранена, обратитесь в службу поддержки Living Security и укажите request_id, метку времени в формате UTC, метод, путь и версию API. Ни в коем случае не передавайте ключ API, секрет клиента или токен доступа.