Azure Logic Apps : contenir le throttling des connecteurs avant d'ajouter des retries

Un workflow Azure Logic Apps synchronise des commandes vers une API SaaS. Après un pic de messages, certaines actions retournent 429 Too Many Requests, les exécutions restent longtemps en cours et le backlog augmente. Le premier réflexe consiste souvent à ajouter des retries ou à augmenter la concurrence pour rattraper le retard. Ces deux changements peuvent multiplier les appels vers une dépendance déjà saturée.

Le runbook doit d’abord localiser la limite : ressource Logic Apps, connexion du connecteur ou système cible. Il doit ensuite contenir la pression, préserver l’ordre et l’idempotence, puis décider entre réduction de concurrence, retry borné, mise en file d’attente, montée en capacité ou rollback.

Geler une fenêtre et un flux représentatif

Ne pars pas d’un total de runs en échec. Choisis un workflow, une action, une connexion et une fenêtre UTC où le symptôme est reproductible.

incident: inc-2026-08-27-logicapps-429
window_utc:
start: 2026-08-27T05:40:00Z
end: 2026-08-27T06:10:00Z
workflow:
resource: la-orders-prod
name: export-orders
trigger: service-bus
action: create_order_in_saas
connection: saas-orders-prod
symptoms:
- action_returns_429
- runs_stay_running
- source_backlog_grows
recent_change:
- trigger_concurrency_increased
decision:
- contain_parallelism
- keep_bounded_retry
- buffer_or_scale
- rollback_last_workflow_revision

Conserve le run ID, l’identifiant métier, le nom de l’action, le nombre de tentatives, les heures de début et de fin, ainsi que l’éventuel en-tête Retry-After. Sans ce périmètre, une moyenne masque facilement un connecteur particulier ou une seule opération lente.

Séparer les trois niveaux de throttling

Un 429 ne désigne pas automatiquement le service SaaS. Le diagnostic doit distinguer trois couches.

Ressource Logic Apps
Plusieurs workflows ou runs consomment la capacite d'execution
Signaux: evenements throttles, runs en attente, hausse globale des 4xx

Connecteur ou connexion API
Une operation depasse la limite du connecteur ou de la connexion
Signaux: 429 concentres sur une action et une connexion

Systeme cible
L'API, la base ou le SaaS refuse les appels qu'il ne peut absorber
Signaux: Retry-After, quotas cibles, logs applicatifs et latence aval

Preuve attendue
Faire correspondre un run Logic Apps a une requete cible
Comparer heure, correlation ID, action, connexion et tentative

Pour un workflow Consumption, consulte les événements d’actions et de déclencheurs throttlés, puis vérifie la connexion utilisée par l’action. Pour un workflow Standard, rapproche les métriques HTTP 4xx, la télémétrie du runtime et les logs de la cible. Le type d’hébergement change les signaux disponibles, pas la nécessité de prouver la couche qui refuse la requête.

Lire les tentatives avant de modifier la policy

L’historique du run indique si une action a été retentée. Les diagnostics envoyés à Log Analytics permettent d’étendre la lecture à plusieurs exécutions.

let Start = datetime(2026-08-27T05:40:00Z);
let End = datetime(2026-08-27T06:10:00Z);
LogicAppWorkflowRuntime
| where TimeGenerated between (Start .. End)
| where WorkflowName == "export-orders"
| extend HasRetry = isnotempty(RetryHistory)
| summarize operations=count(),
          operationsWithRetry=countif(HasRetry),
          failures=countif(Status =~ "Failed"),
          sampleErrors=make_set(Error, 5)
by bin(TimeGenerated, 5m), OperationName
| order by TimeGenerated asc

Puis ouvre quelques runs représentatifs pour lire les entrées, sorties et tentatives de l’action, en protégeant les données sensibles. Une hausse de operationsWithRetry au même moment que le backlog montre une amplification possible ; elle ne prouve pas encore que la cible est saturée. Il faut corréler avec les logs et quotas de la dépendance.

Calculer l’amplification de concurrence

La pression réelle vient de la combinaison entre runs parallèles, boucles For each, Split On et retries. Une estimation haute suffit pour détecter un changement dangereux.

Exemple de borne haute
20 runs simultanes
10 iterations For each en parallele par run
1 appel initial + 4 retries par action

appels possibles = 20 x 10 x 5 = 1 000

Cette valeur n'est pas un volume observe.
Elle sert a verifier si la configuration peut submerger la cible.
Les logs doivent prouver le nombre de tentatives reel.

Le calcul doit aussi inclure les retries du client amont et de la cible lorsqu’ils existent. Plusieurs couches qui retentent indépendamment transforment un ralentissement limité en vague d’appels, même si chacune paraît raisonnable isolément.

Contenir la pression sans perdre le message

La première action doit réduire le nombre de nouveaux appels tout en gardant les données récupérables. Baisse la concurrence du déclencheur ou de la boucle sur un périmètre connu. Désactive temporairement Split On seulement si le workflow sait traiter le tableau sans perdre l’unité de reprise. Ne supprime pas les messages source pour faire baisser un graphique.

{
"triggers": {
  "When_message_received": {
    "runtimeConfiguration": {
      "concurrency": {
        "runs": 4
      }
    }
  }
},
"actions": {
  "Create_order_in_SaaS": {
    "inputs": {
      "retryPolicy": {
        "type": "exponential",
        "count": 2,
        "interval": "PT10S",
        "minimumInterval": "PT10S",
        "maximumInterval": "PT1M"
      }
    }
  }
}
}

Ce fragment illustre une intention, pas une configuration à coller sans vérifier le type exact de déclencheur et d’action. Certaines opérations exposent une retry policy, d’autres non. Versionne le workflow complet, compare le diff et prépare la définition précédente avant le déploiement.

Si la source est une queue, ralentir le consommateur est souvent plus sûr que forcer le débit. Le backlog devient alors un tampon observable. Définis son âge maximal acceptable, sa capacité, la durée de rétention et le propriétaire de la reprise.

Choisir un retry à partir du contrat de l’action

Un retry n’est acceptable que si l’effet précédent est connu ou réconciliable.

GET idempotent avec 429 et Retry-After
Retry borne avec attente compatible avec le budget du workflow

POST protege par une cle d'idempotence
Retry possible apres verification de la cle cote cible

POST sans idempotence, timeout ou reponse ambigue
Ne pas retenter automatiquement
Rechercher l'objet cible avant toute reprise

429 sans origine prouvee
Reduire la concurrence et completer le diagnostic
Ne pas multiplier les connexions pour contourner un quota inconnu

Erreur locale avant l'appel cible
Corriger le workflow ou le connecteur
Augmenter la capacite aval ne changera rien

Respecter Retry-After ne suffit pas si des centaines de runs repartent au même instant. Ajoute de la dispersion lorsque le mécanisme le permet, borne le nombre de tentatives et définis une limite de temps totale. Au-delà, le message doit rester disponible pour une reprise contrôlée ou être dirigé vers un chemin d’échec exploitable.

Valider avec un canary puis reprendre par paliers

Déploie la contention sur une révision ou un workflow de test, puis injecte un petit lot identifiable. Le canary doit prouver le succès nominal et le comportement en cas de 429.

canary:
messages: 10
correlation_prefix: logicapps-429-canary
acceptance:
- no_duplicate_business_effect
- retry_count_at_or_below_approved_limit
- target_429_rate_decreases
- backlog_age_stabilizes
- end_to_end_correlation_remains_visible
resume_steps:
- concurrency_2
- concurrency_4
- concurrency_8_only_if_target_stays_healthy
stop_conditions:
- duplicate_detected
- retry_budget_exceeded
- target_latency_rises_again
- backlog_cannot_be_drained_before_retention_limit

Ne considère pas un run vert comme validation suffisante. Vérifie l’effet métier côté cible, l’absence de doublon, l’âge du backlog et le nombre réel d’appels par identifiant.

Décider correction, capacité ou rollback

Conserve la réduction de concurrence quand elle maintient le débit dans la capacité prouvée de la cible. Ajuste le retry seulement si l’action est sûre, que le délai total est borné et que les tentatives sont visibles. Ajoute une file ou un découplage lorsque les pics sont légitimes mais incompatibles avec le débit aval. N’augmente la capacité qu’après avoir retiré l’amplification artificielle.

Rollbacke la dernière définition lorsque l’incident suit une hausse de concurrence, l’activation de Split On ou une modification de retry, et que la version précédente est connue. Le rollback doit restaurer la définition, vérifier les connexions, exécuter un canary, puis reprendre le backlog par paliers. Il ne doit ni supprimer les messages ni masquer les runs encore ambigus.

Conclusion

Un 429 dans Azure Logic Apps est une décision de capacité distribuée entre runtime, connecteur et cible. Ajouter des retries avant d’avoir identifié cette frontière risque de consommer davantage la ressource qui demande déjà de ralentir.

Le runbook utile relie un run à une requête cible, mesure les tentatives, calcule la concurrence possible, contient le débit et vérifie l’idempotence. La décision finale devient alors exploitable : réduire la concurrence, conserver un retry borné, introduire un tampon, augmenter une capacité prouvée ou rollbacker la définition qui a déclenché l’amplification.