Riprova per le funzioni durevoli Lambda - AWS Lambda
Fase 3 nuovi tentativiEccezioni all'esterno dei gradiniTentativi di backendRiprova le best practice

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Riprova per le funzioni durevoli Lambda

Le funzioni durevoli offrono funzionalità di ripetizione automatica che rendono le applicazioni resilienti ai guasti transitori. L'SDK gestisce i nuovi tentativi a due livelli: ripetuti passaggi per gli errori della logica aziendale e i tentativi di backend per gli errori dell'infrastruttura.

Fase 3 nuovi tentativi

Quando si verifica un'eccezione non rilevata in un passaggio, l'SDK riprova automaticamente il passaggio in base alla strategia di ripetizione configurata. I nuovi tentativi di passaggio sono operazioni bloccate che consentono all'SDK di sospendere l'esecuzione e riprenderla in un secondo momento senza perdere i progressi.

Comportamento dei tentativi successivi

La tabella seguente descrive come l'SDK gestisce le eccezioni all'interno dei passaggi:

Scenario Cosa succede Impatto della misurazione
Eccezione relativa ai tentativi di nuovi tentativi rimanenti L'SDK crea un checkpoint per il nuovo tentativo e sospende la funzione. Alla chiamata successiva, il passaggio riprova con il ritardo di backoff configurato. 1 operazione più errore, dimensione del payload
Eccezione in fase iniziale senza tentativi di riprova rimanenti Il passaggio ha esito negativo e genera un'eccezione. Se il codice del gestore non rileva questa eccezione, l'intera esecuzione fallisce. 1 operazione più errore (dimensione del payload)

Quando è necessario riprovare un passaggio, l'SDK controlla lo stato del nuovo tentativo ed esce dalla chiamata Lambda se non è in esecuzione nessun altro lavoro. Ciò consente all'SDK di implementare ritardi di backoff senza consumare risorse di elaborazione. La funzione riprende automaticamente dopo il periodo di backoff.

Configurazione delle strategie di ripetizione dei passaggi

Configura le strategie di ripetizione dei tentativi per controllare il modo in cui le fasi gestiscono gli errori. È possibile specificare il numero massimo di tentativi, gli intervalli di backoff e le condizioni per i nuovi tentativi.

Backoff esponenziale con numero massimo di tentativi:

TypeScript

const result = await context.step('call-api', async () => {
  const response = await fetch('https://api.example.com/data');
  if (!response.ok) throw new Error(`API error: ${response.status}`);
  return await response.json();
}, {
  retryStrategy: (error, attemptCount) => {
    if (attemptCount >= 5) {
      return { shouldRetry: false };
    }
    // Exponential backoff: 2s, 4s, 8s, 16s, 32s (capped at 300s)
    const delay = Math.min(2 * Math.pow(2, attemptCount - 1), 300);
    return { shouldRetry: true, delay: { seconds: delay } };
  }
});
Python

def retry_strategy(error, attempt_count):
    if attempt_count >= 5:
        return {'should_retry': False}
    # Exponential backoff: 2s, 4s, 8s, 16s, 32s (capped at 300s)
    delay = min(2 * (2 ** (attempt_count - 1)), 300)
    return {'should_retry': True, 'delay': delay}

result = context.step(
    lambda _: call_external_api(),
    name='call-api',
    config=StepConfig(retry_strategy=retry_strategy)
)

Backoff a intervallo fisso:

TypeScript

const orders = await context.step('query-orders', async () => {
  return await queryDatabase(event.userId);
}, {
  retryStrategy: (error, attemptCount) => {
    if (attemptCount >= 3) {
      return { shouldRetry: false };
    }
    return { shouldRetry: true, delay: { seconds: 5 } };
  }
});
Python

def retry_strategy(error, attempt_count):
    if attempt_count >= 3:
        return {'should_retry': False}
    return {'should_retry': True, 'delay': 5}

orders = context.step(
    lambda _: query_database(event['userId']),
    name='query-orders',
    config=StepConfig(retry_strategy=retry_strategy)
)

Riprova condizionale (riprova solo errori specifici):

TypeScript

const result = await context.step('call-rate-limited-api', async () => {
  const response = await fetch('https://api.example.com/data');
  
  if (response.status === 429) throw new Error('RATE_LIMIT');
  if (response.status === 504) throw new Error('TIMEOUT');
  if (!response.ok) throw new Error(`API_ERROR_${response.status}`);
  
  return await response.json();
}, {
  retryStrategy: (error, attemptCount) => {
    // Only retry rate limits and timeouts
    const isRetryable = error.message === 'RATE_LIMIT' || error.message === 'TIMEOUT';
    
    if (!isRetryable || attemptCount >= 3) {
      return { shouldRetry: false };
    }
    
    // Exponential backoff: 1s, 2s, 4s (capped at 30s)
    const delay = Math.min(Math.pow(2, attemptCount - 1), 30);
    return { shouldRetry: true, delay: { seconds: delay } };
  }
});
Python

def retry_strategy(error, attempt_count):
    # Only retry rate limits and timeouts
    is_retryable = str(error) in ['RATE_LIMIT', 'TIMEOUT']
    
    if not is_retryable or attempt_count >= 3:
        return {'should_retry': False}
    
    # Exponential backoff: 1s, 2s, 4s (capped at 30s)
    delay = min(2 ** (attempt_count - 1), 30)
    return {'should_retry': True, 'delay': delay}

result = context.step(
    lambda _: call_rate_limited_api(),
    name='call-rate-limited-api',
    config=StepConfig(retry_strategy=retry_strategy)
)

Disabilita i tentativi:

TypeScript

const isDuplicate = await context.step('check-duplicate', async () => {
  return await checkIfOrderExists(event.orderId);
}, {
  retryStrategy: () => ({ shouldRetry: false })
});
Python

is_duplicate = context.step(
    lambda _: check_if_order_exists(event['orderId']),
    name='check-duplicate',
    config=StepConfig(
        retry_strategy=lambda error, attempt: {'should_retry': False}
    )
)

Quando viene ripristinata la strategia di nuovi tentativishouldRetry: false, il passaggio fallisce immediatamente senza nuovi tentativi. Usalo per operazioni che non devono essere ripetute, come i controlli dell'idempotenza o le operazioni con effetti collaterali che non possono essere ripetuti in sicurezza.

Eccezioni all'esterno dei gradini

Quando si verifica un'eccezione non rilevata nel codice del gestore ma al di fuori di qualsiasi passaggio, l'SDK contrassegna l'esecuzione come non riuscita. Ciò garantisce che gli errori nella logica dell'applicazione vengano rilevati e segnalati correttamente.

Scenario Cosa succede Impatto della misurazione
Eccezione nel codice del gestore al di fuori di qualsiasi passaggio L'SDK contrassegna l'esecuzione come NON RIUSCITA e restituisce l'errore. L'eccezione non viene ritentata automaticamente. Errore nella dimensione del payload

Per abilitare un nuovo tentativo automatico per il codice soggetto a errori, inseriscilo in un unico passaggio con una strategia di riprova. I passaggi prevedono un nuovo tentativo automatico con backoff configurabile, mentre il codice al di fuori dei passaggi fallisce immediatamente.

Tentativi di backend

I nuovi tentativi di backend si verificano quando Lambda rileva guasti dell'infrastruttura, errori di runtime o quando l'SDK non è in grado di comunicare con il servizio di esecuzione durevole. Lambda riprova automaticamente questi errori per garantire che le funzioni durevoli possano essere ripristinate da problemi transitori dell'infrastruttura.

Scenari di nuovi tentativi nel backend

Lambda riprova automaticamente la funzione quando si verificano i seguenti scenari:

  • Errori interni del servizio: quando Lambda o il servizio di esecuzione durevole restituisce un errore 5xx, che indica un problema temporaneo del servizio.

  • Limitazione: quando la funzione viene limitata a causa di limiti di concorrenza o quote di servizio.

  • Timeout: quando l'SDK non riesce a raggiungere il servizio di esecuzione durevole entro il periodo di timeout.

  • Errori di inizializzazione della sandbox: quando Lambda non è in grado di inizializzare l'ambiente di esecuzione.

  • Errori di runtime: quando il runtime Lambda rileva errori esterni al codice della funzione, come out-of-memory errori o arresti anomali del processo.

  • Errori del token di checkpoint non valido: quando il token di checkpoint non è più valido, in genere a causa di modifiche dello stato sul lato del servizio.

La tabella seguente descrive come l'SDK gestisce questi scenari:

Scenario Cosa succede Impatto della misurazione
Errore di runtime esterno al gestore durevole (OOM, timeout, crash) Lambda riprova automaticamente la chiamata. L'SDK riproduce a partire dall'ultimo checkpoint, saltando i passaggi completati. Errore: dimensione del payload + 1 operazione per nuovo tentativo
Errore di servizio (5xx) o timeout durante la chiamata/CheckpointDurableExecutionGetDurableExecutionState APIs Lambda riprova automaticamente la chiamata. L'SDK viene riprodotto a partire dall'ultimo checkpoint. Errore: dimensione del payload + 1 operazione per nuovo tentativo
Limitazione (429) o token di checkpoint non valido durante la chiamata/CheckpointDurableExecutionGetDurableExecutionState APIs Lambda ritenta automaticamente la chiamata con un backoff esponenziale. L'SDK viene riprodotto a partire dall'ultimo checkpoint. Errore: dimensione del payload + 1 operazione per nuovo tentativo
Errore del client (4xx, tranne 429 e token non valido) quando/CheckpointDurableExecutionGetDurableExecutionState APIs L'SDK contrassegna l'esecuzione come NON RIUSCITA. Non si verifica alcun nuovo tentativo automatico perché l'errore indica un problema permanente. Errore: dimensione del payload.

I tentativi di backend utilizzano il backoff esponenziale e continuano fino al successo della funzione o al raggiungimento del timeout di esecuzione. Durante la riproduzione, l'SDK salta i checkpoint completati e continua l'esecuzione dell'ultima operazione riuscita, assicurando che la funzione non riesegua il lavoro completato.

Riprova le best practice

Segui queste best practice per configurare le strategie di riprova:

  • Configura strategie esplicite di nuovi tentativi: non fare affidamento sul comportamento predefinito dei nuovi tentativi in produzione. Configura strategie di riprova esplicite con un numero massimo di tentativi e intervalli di backoff appropriati per il tuo caso d'uso.

  • Utilizza tentativi condizionali: implementa la shouldRetry logica per riprovare solo gli errori transitori (limiti di velocità, timeout) e fallire rapidamente in caso di errori permanenti (errori di convalida, non rilevati).

  • Imposta il numero massimo di tentativi appropriato: equilibrio tra resilienza e tempo di esecuzione. Troppi tentativi possono ritardare il rilevamento degli errori, mentre troppo pochi possono causare errori non necessari.

  • Utilizza il backoff esponenziale: il backoff esponenziale riduce il carico sui servizi a valle e aumenta la probabilità di ripristino da guasti transitori.

  • Raccogli il codice soggetto a errori in fasi: il codice al di fuori dei passaggi non può essere riprovato automaticamente. Raccogli le chiamate API esterne, le query sul database e altre operazioni soggette a errori in fasi con strategie di riprova.

  • Monitora le metriche dei tentativi: monitora le operazioni di ripetizione dei tentativi e gli errori di esecuzione in CloudWatch Amazon per identificare modelli e ottimizzare le strategie di ripetizione dei tentativi.