Documentation

Erreurs HTTP 504 et 502 de séquence OpenWhisk dans Adobe App Builder

Last update: Wed Apr 08 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

Dans Adobe App Builder, les applications qui utilisent des séquences OpenWhisk rencontrent des erreurs HTTP 504 ou HTTP 502 lors de l’exécution d’une action lorsque les actions dépendent de services externes. Ces erreurs se produisent lorsqu’une API externe ne répond pas dans le délai d’exécution OpenWhisk ou lorsque l’environnement d’exécution ne peut pas résoudre un nom d’hôte en raison de problèmes de configuration DNS. Dans ces scénarios, les actions en aval de la séquence échouent également lorsqu’elles tentent de traiter une réponse non définie d’une étape précédente. Pour corriger ce problème, identifiez la dépendance défaillante, validez la résolution DNS, configurez des délais d’expiration plus courts côté client et ajoutez une gestion d’erreur défensive dans les actions de séquence.

Description description

Environnement

  • Produit : Adobe App Builder
  • Runtime: Adobe I/O Runtime (OpenWhisk)
  • Source de déclenchement : Adobe I/O Events intégrations basées sur des événements

Contraintes d’exécution standard :

Composant
Temporisation
Délai de diffusion des événements I/O
60 secondes
Délai d’expiration de l’action OpenWhisk
60 secondes
Délai d’exécution de la séquence
60 secondes

Ces limites s’appliquent lorsque les actions s’exécutent de manière synchrone dans une séquence.

Problème/Symptômes

Symptôme 1 - Délai d'expiration de la passerelle HTTP 504 du contrôleur OpenWhisk

Lorsqu’une action dépasse la limite d’exécution, le contrôleur OpenWhisk renvoie une erreur HTTP 504.

Exemple de modèle de journal d’activation :

sequence execution failed OpenWhiskError:
POST https://controller-gw.../actions/<sequence-name>
Returned HTTP 504 (Gateway Timeout)Error:
"The action exceeded its time limits of 60000 milliseconds"

Cela signifie que l’action s’est exécutée jusqu’à la limite d’exécution maximale sans réussir.

Cause typique :
Une requête d’API sortante de l’action attend indéfiniment une réponse.

Symptôme 2 - HTTP 502 avec erreur d’application

Lorsqu’une action échoue en interne avant d’atteindre le délai d’exécution, OpenWhisk renvoie une réponse HTTP 502 avec une erreur au niveau de l’application.

Exemple de journal :

sequence execution failed OpenWhiskError:
Returned HTTP 502 (Bad Gateway) --> "application error, status code: 500"

Cela signifie que l’action a rencontré une erreur lors de l’exécution et a renvoyé un statut d’échec.

Symptôme 3 - Échec de la résolution DNS pour les requêtes API sortantes

Lorsqu’une action appelle un nom d’hôte externe qui ne peut pas être résolu, les journaux affichent les erreurs liées au DNS.

Exemple de modèle d’erreur :

Error: getaddrinfo ENOTFOUND api.example.com

Cela signifie que l’environnement d’exécution ne peut pas résoudre le nom d’hôte utilisé par l’action pour les requêtes sortantes.

Symptôme 4 - Erreur de type en aval dans le gestionnaire de séquences

Lorsqu’une action précédente échoue ou expire, les étapes de séquence en aval tentent de traiter une réponse non définie.

Exemple d’erreur d’exécution :

TypeError: Cannot read properties of undefined (reading 'result')

Cela se produit lorsque les gestionnaires de séquences supposent une réponse valide d’une étape précédente qui a échoué.

Cause

Ces erreurs sont dues à deux causes profondes courantes.

1. Latence ou absence de réponse de l’API externe
Lorsqu’une action OpenWhisk appelle un service externe qui ne répond pas dans la fenêtre d’exécution configurée, l’action continue d’attendre que le délai d’expiration OpenWhisk soit atteint.
Une fois le délai dépassé, l’exécution met fin à l’action et le contrôleur renvoie une erreur HTTP 504.

2. Échecs de résolution DNS des requêtes sortantes
Lorsque le nom d’hôte utilisé par l’action ne peut pas être résolu via DNS, la requête sortante échoue immédiatement.
L’action renvoie ensuite une erreur d’application, souvent HTTP 500, qui apparaît à l’appelant sous la forme d’une erreur HTTP 502.

Ces deux problèmes proviennent de dépendances au niveau de l’application et non de problèmes d’infrastructure de la plateforme.

Résolution resolution

Pour résoudre le problème, procédez comme suit :

  1. Vérifier la disponibilité de l’API externe

    Vérifiez que le point d’entrée externe de l’API appelé par l’action OpenWhisk est accessible et répond normalement.

    Testez le point d’entrée avec une requête directe :

    code language-none 
    curl https://api.example.com/endpoint

    Résultat attendu :

    1. La requête renvoie une réponse HTTP valide.
    2. Le temps de réponse reste dans des limites acceptables, généralement quelques secondes.

    Si la requête se bloque ou prend trop de temps :

    1. Vérifiez que le service externe est opérationnel.
    2. Vérifiez que l’URL du point d’entrée est correcte.
    3. Vérifiez les restrictions de pare-feu ou de réseau affectant le trafic sortant.
    4. Contactez le fournisseur d’API si le service semble endommagé.

  2. Implémenter des délais d’expiration client HTTP plus courts

    Les appels externes provenant d’actions OpenWhisk doivent utiliser un délai d’expiration côté client inférieur à la limite d’exécution de la plateforme.

    Cela empêche l’action d’attendre jusqu’à la temporisation complète de 60 secondes.

    Exemple d’implémentation à l’aide d’un client HTTP Node.js :

    code language-none 
    const axios = require("axios")

await axios.get("https://api.example.com/endpoint",
  { timeout: 8000 }
)

    Pratique recommandée :

    1. Configurez les délais d’expiration HTTP sortants compris entre 5 et 10 secondes.
    2. Gérez explicitement les exceptions de délai d’expiration dans la logique d’action.

    Cela garantit que l’action échoue rapidement au lieu de consommer toute la fenêtre d’exécution.

  3. Validation de la configuration DNS

    Si les journaux affichent des erreurs ENOTFOUND, vérifiez que le nom d’hôte utilisé par l’action est correctement résolu.

    Utilisez les outils de recherche DNS tels que :

    code language-none 
    nslookup api.example.com

    or

    code language-none 
    dig api.example.com

    Résultat attendu :

    La commande renvoie une adresse IP pour le nom d’hôte.

    code language-none 
    Name: api.example.com
Address: <IP address>

    Si aucune adresse IP n’est renvoyée :

    1. Vérifiez que le nom d’hôte est correct.
    2. Vérifiez que l’enregistrement DNS existe.
    3. Vérifiez l'état de propagation du DNS.
    4. Assurez-vous qu’aucune restriction DNS interne ne bloque la résolution.

  4. Ajout de la gestion des erreurs défensives dans les séquences d’action

    Mettez à jour les gestionnaires de séquence pour gérer les échecs en amont et éviter de supposer que les actions précédentes ont renvoyé des réponses valides.

    Exemple de mesure de sauvegarde :

    code language-none 
    if (!response || !response.result) {
  return
  { error: "Upstream action failed or timed out" }
}

    Cela évite les erreurs d’exécution en aval lorsque les étapes de séquence précédentes échouent.

Vérification

Après avoir appliqué les modifications recommandées, vérifiez que le problème ne se produit plus.

  1. Déclenchez à nouveau l’action ou l’événement App Builder.

  2. Ouvrez la console App Builder et vérifiez les journaux d’activation.

  3. Confirmez les résultats suivants :

    • Aucune erreur HTTP 504 n’apparaît.
    • Aucune erreur d’application HTTP 502 ne se produit.
    • Les requêtes d’API externes sont terminées dans le délai configuré.
    • Les gestionnaires de séquence renvoient des réponses valides.

Une activation réussie affiche un statut similaire au suivant :

status: success
duration: < expected runtime

Le temps d’exécution total doit rester bien inférieur à la limite de 60 secondes.

Remarques complémentaires

Comportement de Platform

L’exécution OpenWhisk applique une limite d’exécution stricte pour les actions qui s’exécutent dans des séquences. Lorsqu’une action atteint cette limite, l’exécution met automatiquement fin à l’action.
Une réponse HTTP 504 du contrôleur confirme que la limite d’exécution a été atteinte.

Gestionnaires d'événements gérés

Certains workflows Adobe App Builder invoquent des actions gérées par Adobe, telles que des gestionnaires d’événements pour Adobe I/O Events. Ces actions s’exécutent dans le cadre de la séquence, mais sont conservées par Adobe et ne nécessitent aucune modification.

Recommandations de surveillance

Pour réduire le risque de problèmes similaires :

  1. Surveillez la latence des API externes.
  2. Implémentez des reprises avec une interruption exponentielle.
  3. Enregistrez les durées des requêtes d’API sortantes.
  4. Suivre les temps d’exécution des actions dans les journaux d’activation.

Ces pratiques permettent d’identifier les dépendances externes qui entraînent des retards d’exécution.

Lecture connexe

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f