Le caratteristiche di ripetizione dei tentativi di Eventarc corrispondono a quelle del suo livello di trasporto, Cloud Pub/Sub. Per maggiori informazioni, consulta le sezioni Riprovare le richieste e Push backoff.
La durata predefinita di conservazione dei messaggi impostata da Eventarc è di 24 ore con un ritardo di backoff esponenziale.
Puoi aggiornare la policy di nuovi tentativi tramite la sottoscrizione Pub/Sub associata al trigger 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
delle sottoscrizioni, consulta
Limiti delle risorse Pub/Sub.
Se Pub/Sub tenta di consegnare un messaggio, ma la destinazione non può confermarlo, Pub/Sub invierà nuovamente il messaggio con un backoff esponenziale minimo di 10 secondi. Se la destinazione continua a non confermare il messaggio, viene aggiunto più tempo al ritardo in ogni nuovo tentativo (fino a un massimo di 600 secondi) e il messaggio viene inviato nuovamente alla destinazione.
Tieni presente che Workflows riconosce gli eventi non appena inizia l'esecuzione del workflow.
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ò archiviare i messaggi che la destinazione non può riconoscere. Devi impostare unargomento messaggi non recapitabilir quando crei o aggiorni una sottoscrizione Pub/Sub, non quando crei un argomento Pub/Sub o quando Eventarc crea un argomento Pub/Sub. Per ulteriori informazioni, consulta la sezione Gestire gli errori dei messaggi.
Errori che non giustificano i nuovi tentativi
Quando le applicazioni utilizzano Pub/Sub come origine eventi e l'evento non viene recapitato, viene ritentato automaticamente, ad eccezione degli errori che non giustificano i nuovi tentativi. Gli eventi alla destinazione del flusso di lavoro da qualsiasi origine non verranno riprovati se il flusso di lavoro non viene eseguito. Se l'esecuzione del workflow inizia, ma non va a buon fine, i tentativi non vengono ripetuti. Per risolvere questi problemi del servizio, devi gestire gli errori e i tentativi all'interno del flusso di lavoro.
Duplicare gli eventi
Gli eventi duplicati potrebbero essere inviati ai gestori di eventi. Secondo la
specifica CloudEvents,
la combinazione degli attributi source e id è considerata univoca e
pertanto tutti gli eventi con la stessa combinazione sono considerati duplicati.
Come best practice generale, devi implementare i gestori di eventi idempotenti.
Rendi idempotenti i gestori di eventi
I gestori di eventi che possono essere riprovati devono essere idempotenti e seguire le seguenti linee guida generali:
- Molte API esterne ti consentono di fornire una chiave di idempotenza come parametro. Se utilizzi un'API di questo tipo, devi utilizzare l'ID evento come chiave di idempotenza.
- L'idempotenza funziona bene con la consegna "at-least-once", perché rende sicuro il nuovo tentativo. Pertanto, una best practice generale per scrivere codice affidabile è combinare l'idempotenza con i tentativi.
- Assicurati che il codice sia idempotente internamente. 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.
- Imponi un controllo transazionale al di fuori del tuo servizio, indipendentemente dal codice. Ad esempio, mantieni lo stato in un punto in cui viene registrato che un determinato ID evento è già stato elaborato.
- Gestisci le chiamate duplicate fuori banda. Ad esempio, esegui un processo di pulizia separato che pulisce dopo le chiamate duplicate.