Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Idempotence

Les fonctions durables fournissent une idempuissance intégrée pour les démarrages d'exécution grâce aux noms d'exécution. Lorsque vous fournissez un nom d'exécution, Lambda l'utilise pour empêcher les doubles exécutions et permettre de nouvelles tentatives d'appel en toute sécurité. Les étapes ont une sémantique at-least-once d'exécution par défaut : lors de la réexécution, le SDK renvoie des résultats précis sans réexécuter les étapes terminées, mais votre logique métier doit être idempotente pour gérer d'éventuelles nouvelles tentatives avant la fin.

Noms d'exécution

Vous pouvez fournir un nom d'exécution lorsque vous invoquez une fonction durable. Le nom d'exécution agit comme une clé d'impuissance, vous permettant de réessayer les demandes d'invocation en toute sécurité sans créer de doublons d'exécutions. Si vous ne fournissez pas de nom, Lambda génère automatiquement un identifiant d'exécution unique.

Les noms d'exécution doivent être uniques au sein de votre compte et de votre région. Lorsque vous invoquez une fonction dont le nom d'exécution existe déjà, le comportement de Lambda dépend de l'état de l'exécution existante et de la correspondance de la charge utile.

Comportement d'impuissance

Le tableau suivant décrit comment Lambda gère les demandes d'invocation selon que vous fournissez un nom d'exécution, l'état d'exécution existant et si la charge utile correspond :

Remarque

Les scénarios 3 et 5 illustrent un comportement idempotent dans lequel Lambda gère en toute sécurité les demandes d'invocation dupliquées en renvoyant les informations d'exécution existantes au lieu de créer des doublons.

Étape 1 : Idempuissance

Les étapes ont une sémantique at-least-once d'exécution par défaut. Lorsque votre fonction est rejouée après une attente, un rappel ou un échec, le SDK compare chaque étape au journal des points de contrôle. Pour les étapes déjà terminées, le SDK renvoie le résultat du point de contrôle sans réexécuter la logique des étapes. Toutefois, si une étape échoue ou si la fonction est interrompue avant la fin de l'étape, l'étape peut être exécutée plusieurs fois.

Votre logique métier articulée en étapes doit être idempotente pour gérer d'éventuelles nouvelles tentatives. Utilisez des clés d'idempuissance pour garantir que les opérations telles que les paiements ou les écritures de base de données ne s'exécutent qu'une seule fois, même si l'étape est réessayée.

Exemple : utilisation des clés d'idempuissance par étapes

TypeScript

import { withDurableExecution, DurableContext } from '@aws/durable-execution-sdk-js';
import { randomUUID } from 'crypto';

export const handler = withDurableExecution(
  async (event: any, context: DurableContext) => {
    // Generate idempotency key once
    const idempotencyKey = await context.step('generate-key', async () => {
      return randomUUID();
    });
    
    // Use idempotency key in payment API to prevent duplicate charges
    const payment = await context.step('process-payment', async () => {
      return paymentAPI.charge({
        amount: event.amount,
        idempotencyKey: idempotencyKey
      });
    });
    
    return { statusCode: 200, payment };
  }
);
          

Python

from aws_durable_execution_sdk_python import durable_execution, DurableContext
import uuid

@durable_execution
def handler(event, context: DurableContext):
    # Generate idempotency key once
    idempotency_key = context.step(
        lambda _: str(uuid.uuid4()),
        name='generate-key'
    )
    
    # Use idempotency key in payment API to prevent duplicate charges
    payment = context.step(
        lambda _: payment_api.charge(
            amount=event['amount'],
            idempotency_key=idempotency_key
        ),
        name='process-payment'
    )
    
    return {'statusCode': 200, 'payment': payment}
          

Vous pouvez configurer les étapes pour utiliser la sémantique at-most-once d'exécution en définissant le mode d'exécution sur. AT_MOST_ONCE_PER_RETRY Cela garantit que l'étape s'exécute au maximum une fois par nouvelle tentative, mais peut ne pas s'exécuter du tout si la fonction est interrompue avant la fin de l'étape.

Le SDK applique la rediffusion déterministe en vérifiant que les noms et l'ordre des étapes correspondent au journal des points de contrôle lors de la rediffusion. Si votre code tente d'exécuter des étapes dans un ordre différent ou avec des noms différents, le SDK lance unNonDeterministicExecutionError.

Comment fonctionne le replay une fois les étapes terminées :

Ce mécanisme de réexécution garantit que les étapes terminées ne sont pas réexécutées, mais votre logique métier doit toujours être idempotente pour gérer les nouvelles tentatives avant leur fin.