Le caratteristiche di ripetizione di Eventarc corrispondono a quelle del suo livello di trasporto, Cloud Pub/Sub. Per ulteriori informazioni, consulta la sezione Riprova le richieste e Ritiro push.
La durata di conservazione dei messaggi predefinita impostata da Eventarc è di 24 ore con un ritardo di backoff esponenziale.
Puoi aggiornare la regola di ripetizione tramite l'abbonamento Pub/Sub associato all'attivatore Eventarc:
- Apri la pagina Dettagli trigger.
- Fai clic sull'argomento.
- Fai clic sulla scheda Sottoscrizioni.
Qualsiasi abbonamento
creato automaticamente da Eventarc avrà questo formato:
projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Per ulteriori informazioni sui limiti di abbonamento, consulta Limiti delle risorse Pub/Sub.
Se Pub/Sub tenta di consegnare un messaggio, ma la destinazione non può confermarlo, lo invierà di nuovo con un backoff esponenziale minimo di 10 secondi. Se la destinazione continua a non confermare il messaggio, a ogni nuovo tentativo viene aggiunto altro tempo al ritardo (fino a un massimo di 600 secondi) e il messaggio viene inviato di nuovo alla destinazione.
Tieni presente che Workflows conferma gli eventi non appena inizia la esecuzione del flusso di lavoro.
Argomenti messaggi non recapitabili
Se la destinazione non riceve il messaggio, puoi inoltrare i messaggi non recapitati a un argomento messaggi non recapitabili (noto anche come coda messaggi non recapitabili). Un argomento messaggi non recapitabili può memorizzare i messaggi che la destinazione non è in grado di confermare. Devi impostare un argomento per le email in arrivo quando crei o aggiorni una sottoscrizione Pub/Sub, non quando crei un argomento Pub/Sub o quando Eventarc ne crea uno. Per ulteriori informazioni, consulta la sezione Gestire gli errori dei messaggi.
Errori che non richiedono ulteriori tentativi
Quando le applicazioni utilizzano Pub/Sub come origine evento e l'evento non viene recapitato, viene riprovato automaticamente, tranne per gli errori che non richiedono ripetuti tentativi. Gli eventi destinati alla destinazione del flusso di lavoro da qualsiasi origine non verranno riprovati se il flusso di lavoro non viene eseguito. Se l'esecuzione del flusso di lavoro viene avviata, ma in un secondo momento non va a buon fine, le esecuzioni non vengono ripetute. Per risolvere questi problemi di servizio, devi gestire gli errori e i riprova all'interno del flusso di lavoro.
Eventi duplicati
Gli eventi duplicati potrebbero essere inviati ai gestori di eventi. In base alla
specifica CloudEvents,
la combinazione di attributi source e id è considerata univoca e
di conseguenza tutti gli eventi con la stessa combinazione sono considerati duplicati.
Come best practice generale, devi implementare gestori di eventi idempotenti.
Rendi idempotenti i gestori di eventi
I gestori di eventi che possono essere riprovati devono essere idempotenti, utilizzando le seguenti linee guida generali:
- Molte API esterne ti consentono di fornire una chiave di iride come parametro. Se utilizzi un'API di questo tipo, devi utilizzare l'ID evento come chiave di iride.
- L'idempotenza funziona bene con la consegna "almeno una volta", perché consente di ritentare in sicurezza. Pertanto, una best practice generale per scrivere codice affidabile è combinare l'idempotenza con i tentativi di nuovo.
- Assicurati che il codice sia internamente idempotente. Ad esempio:
- Assicurati che le mutazioni possano verificarsi più di una volta senza modificare il risultato.
- Esegui query sullo stato del database in una transazione prima di modificarlo.
- Assicurati che tutti gli effetti collaterali siano idempotenti.
- Imposta un controllo transazionale esterno al tuo servizio, indipendentemente dal codice. Ad esempio, mantieni lo stato da qualche parte registrando che un determinato ID evento è stato già elaborato.
- Gestire le chiamate duplicate out-of-band. Ad esempio, puoi avere un processo di pulizia distinto per le chiamate duplicate.