As características de nova tentativa do Eventarc correspondem às da camada de transporte, o Cloud Pub/Sub. Para mais informações, consulte Novas tentativas de solicitações e Espera de push.
A duração padrão de retenção de mensagens definida pelo Eventarc é de 24 horas com um atraso de espera exponencial.
É possível atualizar a política de nova tentativa pela assinatura do Pub/Sub associada ao gatilho do Eventarc:
- Abra a página Detalhes do gatilho.
- Clique no tópico.
- Clique na guia Assinaturas.
Qualquer assinatura
criada automaticamente pelo Eventarc terá este formato:
projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID. Para mais informações sobre limites
de assinatura, consulte
Limites de recursos do Pub/Sub.
Se o Pub/Sub tentar entregar uma mensagem, mas o destino não conseguir reconhecê-la, o Pub/Sub vai enviar a mensagem novamente com uma espera exponencial mínima de 10 segundos. Se o destino ainda não confirmar a mensagem, mais tempo será adicionado ao atraso em cada nova tentativa (até o máximo de 600 segundos) e a mensagem será reenviada para o destino.
O Workflows reconhece eventos assim que a execução do fluxo de trabalho é iniciada.
Tópicos de mensagens inativas
Se o destino não receber a mensagem, será possível encaminhar as mensagens não entregues para um tópico de mensagens inativas (também conhecido como fila de mensagens inativas). Um tópico de mensagens inativas pode armazenar mensagens que o destino não consegue confirmar. Defina um tópico de mensagens inativas ao criar ou atualizar uma assinatura do Pub/Sub, não ao criar um tópico do Pub/Sub ou quando o Eventarc cria um tópico do Pub/Sub. Para saber mais, consulte Como corrigir falhas nas mensagens.
Erros que não garantem novas tentativas
Quando os aplicativos usam o Pub/Sub como a fonte do evento e o evento não é entregue, ele é repetido automaticamente, com exceção dos erros que não garantem novas tentativas. Não ocorrerão novas tentativas de eventos de nenhuma origem para o destino do fluxo de trabalho. Se a execução do fluxo de trabalho começar, mas depois falhar, as execuções não serão repetidas. Para resolver esses problemas de serviço, você precisa processar erros e novas tentativas no fluxo de trabalho.
Duplicar eventos
Eventos duplicados podem ser entregues aos manipuladores de eventos. De acordo com a
especificação do CloudEvents,
a combinação dos atributos source e id é considerada única e, portanto,
todos os eventos com a mesma combinação são considerados duplicados.
Implemente manipuladores de eventos idempotentes
como prática recomendada geral.
Tornar manipuladores de eventos idempotentes
Os manipuladores de eventos que podem ser repetidos precisam ser idempotentes. Para isso, siga as seguintes diretrizes gerais:
- Muitas APIs externas permitem o fornecimento de uma chave de idempotência como um parâmetro. Se você estiver usando uma API como essa, utilize o ID do evento como chave de idempotência.
- A idempotência funciona bem com a entrega do tipo "pelo menos uma vez", porque torna as novas tentativas mais seguras. Dessa forma, para escrever um código confiável, a prática recomendada é combinar idempotência com tentativas.
- Verifique se o código é idempotente internamente. Por exemplo:
- Garanta que mutações possam ocorrer mais de uma vez sem alterar o resultado.
- Consulte o estado do banco de dados em uma transação antes de alterar o estado.
- Certifique-se de que todos os efeitos colaterais sejam idempotentes.
- Execute uma verificação transacional fora do serviço, independente do código. Por exemplo, mantenha a persistência de estado em algum local e registre que um determinado código de evento já foi processado.
- Lide com chamadas duplicadas fora da banda. Por exemplo, tenha um processo de limpeza separado que seja executado após chamadas duplicadas.