Google est engagé à faire progresser l'équité raciale pour les communautés noires. Regarde comment.
Cette page a été traduite par l'API Cloud Translation.
Switch to English

Réessayez fonctions asynchrones

Ce document décrit comment vous pouvez demander des fonctions asynchrones de fond (non-HTTPS) pour retenter en cas d'échec.

Sémantique de nouvelle tentative

Nuage Fonctions garanties au-moins-une fois que l'exécution d'une fonction d'arrière-plan pour chaque événement émis par une source d'événements. Toutefois, par défaut, si un appel de fonction se termine par une erreur, la fonction ne sera pas d'être choisie, et l'événement sera abandonné. Lorsque vous activez une fonction sur retries d'arrière-plan, les fonctions de Cloud nouvelle tentative d'un appel de fonction a échoué jusqu'à ce qu'elle se termine avec succès, ou la fenêtre de nouvelle tentative (par défaut, 7 jours) expire.

Pourquoi les fonctions de base ne terminent pas

À de rares occasions, une fonction peut quitter prématurément en raison d'une erreur interne, et par défaut, la fonction peut ou non être automatiquement rejugé.

Plus généralement, une fonction d'arrière-plan peut échouer à cause avec succès complet des erreurs lancées dans le code de la fonction elle-même. Certaines des raisons pour lesquelles cela pourrait se produire sont les suivantes:

  • La fonction contient un bug et le moteur d'exécution renvoie une exception.
  • La fonction ne peut pas atteindre un point de terminaison de service ou hors temps tout en essayant d'atteindre le point final.
  • La fonction lance intentionnellement une exception (par exemple, lorsqu'un paramètre validation échoue).
  • Lorsque des fonctions écrites dans Node.js renvoient une promesse rejetée ou passer une non null valeur à un rappel.

Dans tous les cas ci-dessus, la fonction arrête l'exécution par défaut et l'événement est mis au rebut. Si vous souhaitez recommencer la fonction en cas d'erreur, vous pouvez modifier la stratégie de nouvelle tentative par défaut en définissant la propriété « nouvelle tentative en cas d' échec » . Cela provoque l'événement à plusieurs reprises rejugé jusqu'à plusieurs jours jusqu'à ce que la fonction se termine avec succès.

Activation et désactivation des tentatives

Utilisation de la console GCP

Vous pouvez activer ou désactiver dans la retries GCP Console comme suit:

  1. Accédez au fonctions de Cloud page Aperçu dans la Console Cloud Platform.

  2. Cliquez sur Créer la fonction. Vous pouvez également cliquer sur une fonction existante pour aller à la page ses détails et cliquez sur Modifier.

  3. Remplissez les champs requis pour votre fonction.

  4. Vérifiez que le champ Trigger est réglé sur un type de déclenchement de la fonction d'arrière - plan, comme le Cloud Pub / Sub ou Cloud Storage.

  5. Développez les paramètres avancés en cliquant sur Plus.

  6. Cochez ou décochez la case Retry en cas d' échec.

Les meilleures pratiques

Cette section décrit les meilleures pratiques pour l'utilisation de relances.

Utilisez nouvelle tentative pour gérer les erreurs transitoires

Parce que votre fonction est rejugé en continu jusqu'à une exécution réussie, les erreurs permanentes comme des bugs devraient être éliminés de votre code grâce aux tests avant d'activer relances. Tentatives sont mieux utilisées pour manipuler intermittents / défaillances transitoires qui ont une forte probabilité de résolution sur une nouvelle tentative, comme un point de terminaison de service squameuse ou délai d'attente.

Définir une condition de fin pour éviter les boucles infinies de nouvelles tentatives

Il est la meilleure pratique pour protéger votre fonction contre mise en boucle continue lors de l'utilisation retries. Vous pouvez le faire en incluant une condition de fin bien définie, avant que la fonction commence le traitement. Notez que cette technique ne fonctionne que si votre fonction démarre correctement et est en mesure d'évaluer l'état final.

Une approche simple et efficace aux événements défausse avec horodatages âgés de plus d'un certain temps. Cela permet d'éviter les exécutions excessives en cas de défaillance sont soit persistante ou de plus longue durée que prévu.

Par exemple, ce code snippet rejets tous les événements de plus de 10 secondes:

 const eventAgeMs = Date.now() - Date.parse(event.timestamp);
const eventMaxAgeMs = 10000;
if (eventAgeMs > eventMaxAgeMs) {
  console.log(`Dropping event ${event} with age[ms]: ${eventAgeMs}`);
  callback();
  return;
}
 

Utiliser catch avec des promesses

Si votre fonction a permis relances, toute erreur non gérée déclenchera une nouvelle tentative. Assurez-vous que votre code capture toute erreur qui ne devrait pas donner lieu à une nouvelle tentative.

Voici un exemple de ce que vous devez faire:

 return doFooAsync().catch((err) => {
    if (isFatal(err)) {
        console.error(`Fatal error ${err}`);
    }
    return Promise.reject(err);
});
 

Faire des fonctions de base réessayable idempotent

fonctions d'arrière-plan qui peuvent être rejugés doivent être idempotent. Voici quelques directives générales pour la réalisation d'une fonction d'arrière-plan idempotent:

  • De nombreuses API externes (tels que Stripe) vous permettent de fournir une clé de idempotence en tant que paramètre. Si vous utilisez une telle API, vous devez utiliser l'ID d'événement comme la clé de idempotence.
  • Idempotence fonctionne bien avec au-moins une fois la livraison, car il rend sûr de nouvelle tentative. Ainsi, une meilleure pratique générale pour écrire du code fiable est de combiner idempotence avec relances.
  • Assurez-vous que votre code est interne idempotente. Par exemple:
    • Assurez-vous que des mutations peuvent se produire plus d'une fois sans changer le résultat.
    • état de la base de données de requête dans une transaction avant de muter l'État.
    • Assurez-vous que tous les effets secondaires sont eux-mêmes idempotent.
  • Imposer un contrôle transactionnel en dehors de la fonction, indépendamment du code. Par exemple, conserver l'état d'enregistrement quelque part qu'un ID d'événement donné a déjà été traité.
  • Traiter les appels de fonction en double hors bande. Par exemple, un processus de nettoyage séparé qui nettoie après les appels de fonction en double.