Vous avez une fonction Azure déclenchée par un Service Bus qui appelle une API en aval soumise à des limitations. En cas d'échecs transitoires, vous souhaitez effectuer jusqu'à 5 tentatives avec un backoff exponentiel et des délais allant de 2 secondes à 1 minute. Après les tentatives, le message doit être placé dans la file d'attente des messages non livrés par Service Bus. Comment devez-vous configurer les tentatives ?

La bonne réponse configure la politique de nouvelle tentative directement dans le fichier host.json de l'application de fonction Azure. La stratégie exponentialBackoff est spécifiée, ce qui correspond à l'exigence de délais croissants entre les tentatives. maxRetryCount est défini sur 5, comme demandé. Les paramètres minimumInterval et maximumInterval définissent la plage des délais de backoff, de 2 secondes à 1 minute, ce qui est conforme aux exigences. Lorsque toutes les tentatives échouent, le message est automatiquement déplacé vers la file d'attente des messages non livrés de Service Bus par le déclencheur Service Bus. L'option avec fixedDelay est incorrecte car elle ne met pas en œuvre un backoff exponentiel. Définir MaxDeliveryCount sur 5 dans Service Bus est une mesure de sécurité, mais cela ne gère pas la logique de nouvelle tentative avec backoff exponentiel au niveau de la fonction et ne renvoie pas le message à la file d'attente des messages non livrés après des échecs transitoires gérés par la fonction. Implémenter Polly dans le code est une option, mais la configuration host.json est la méthode préférée et plus simple pour les scénarios de nouvelle tentative au niveau du déclencheur, évitant le code boilerplate.