Le caratteristiche di nuovo tentativo di Eventarc corrispondono a quelle del suo livello di trasporto, Cloud Pub/Sub. Per ulteriori informazioni, vedi Ripetere le richieste e Eseguire il push di backoff.
La durata predefinita di conservazione dei messaggi impostata da Eventarc è di 24 ore con un ritardo di backoff esponenziale.
Puoi aggiornare il criterio di nuovo tentativo tramite la sottoscrizione Pub/Sub associata al trigger Eventarc:
- Apri la pagina dei dettagli dell'attivatore.
- 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 degli abbonamenti, consulta Limiti delle risorse Pub/Sub.
Se Pub/Sub tenta di recapitare un messaggio, ma la destinazione non riesce a confermarlo, Pub/Sub invierà di nuovo il messaggio con un backoff esponenziale minimo di 10 secondi. Se la destinazione continua a non riconoscere il messaggio, viene aggiunto altro tempo al ritardo in ogni nuovo tentativo (fino a un massimo di 600 secondi) e il messaggio viene inviato nuovamente alla destinazione.
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 messaggi che la destinazione non può riconoscere. Devi impostare un argomento messaggi non recapitabili 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 Gestire gli errori relativi ai messaggi.
Errori che non giustificano nuovi tentativi
Quando le applicazioni utilizzano Pub/Sub come origine dell'evento e l'evento non viene consegnato, viene eseguito automaticamente un nuovo tentativo, ad eccezione degli errori che non giustificano l'esecuzione di nuovi tentativi. Tieni presente che Workflows riconosce gli eventi non appena inizia l'esecuzione del flusso di lavoro. Gli eventi nella destinazione del flusso di lavoro da qualsiasi origine non verranno tentati se il flusso di lavoro non viene eseguito. Se l'esecuzione del flusso di lavoro inizia ma in seguito non va a buon fine, le esecuzioni non vengono tentate di nuovo. Per risolvere questi problemi relativi ai servizi, è necessario gestire gli errori e i nuovi tentativi all'interno del flusso di lavoro.
Duplicare gli eventi
È possibile che eventi duplicati vengano inviati ai gestori di eventi. In base alla specifica CloudEvents, la combinazione degli attributi source e id è considerata univoca, pertanto tutti gli eventi con la stessa combinazione sono considerati duplicati.
Dovresti implementare gestori di eventi idempotenti come best practice generale.
Rendi i gestori di eventi idempotenti
I gestori di eventi che possono essere ritentati devono essere idempotenti, utilizzando 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'idempotency funziona bene con la distribuzione "at-least-once", perché consente di riprovare in sicurezza. Quindi una best practice generale per la scrittura di codice affidabile è combinare l'idempotenza con i nuovi tentativi.
- Assicurati che il tuo codice sia internamente idempotente. Ad esempio:
- Assicurati che le mutazioni possano verificarsi più di una volta senza cambiare il risultato.
- Esegui una query sullo stato del database in una transazione prima di modificarne lo stato.
- Assicurati che tutti gli effetti collaterali siano idempotenti.
- Imponi un assegno transazionale al di fuori del tuo servizio, indipendentemente dal codice. Ad esempio, lo stato persistente in un punto in cui è registrato che un determinato ID evento è già stato elaborato.
- Gestisci le chiamate fuori banda duplicate. Ad esempio, avere un processo separato di pulizia dopo chiamate duplicate.