Ваш шлюз APIM перенаправляет запросы в бэкенд, который периодически возвращает ошибки 500 или 504. Вы должны повторять неудачные вызовы до трех раз с задержкой в одну секунду, но только для этих двух кодов состояния. Какую конфигурацию политики вы должны использовать?

Правильный ответ — обернуть вызов бэкенда политикой повторных попыток с условием. Политика <retry в Azure API Management позволяет повторно отправлять запросы к бэкенду при определенных условиях. Атрибут count="3" устанавливает максимальное количество повторных попыток равным трем, а interval="1" задает задержку в одну секунду между попытками. Атрибут condition="@(context.Response.StatusCode == 500 || context.Response.StatusCode == 504)" гарантирует, что повторные попытки будут выполняться только в случае получения кодов состояния HTTP 500 или 504 от бэкенда, что соответствует требованиям задачи. Внутри политики <retry находится <forward-request /, который перенаправляет исходный запрос к бэкенду. Неправильные варианты: Повторные попытки без условия будут повторять все неудачные запросы, а не только те, которые соответствуют кодам 500 или 504. Использование политики set-variable и JavaScript для зацикливания является излишне сложным и не является стандартным способом обработки повторных попыток в APIM. Установка таймаута на forward-request не приводит к автоматическим повторным попыткам в случае ошибок бэкенда; таймаут просто прерывает запрос, если он не завершается в течение указанного времени.