Conceito e mecanismo
O trigger determina como uma função é invocada. Input e output bindings ligam dados à execução, mas não eliminam requisitos de autorização ou tratamento de falhas. Uma função tem um trigger e pode ter vários bindings adicionais. O comportamento de retry depende do trigger e da extensão; não transfiras uma configuração de um mecanismo para outro sem confirmação. Para políticas de execução suportadas, esconder a exceção e terminar com sucesso pode impedir a repetição esperada. Distingue falhas transitórias de dados que continuarão inválidos numa nova tentativa.
Aplicação guiada
Para operações com efeito externo, define um identificador estável e um estado durável. Documenta o que acontece se houver falha antes do efeito, depois do efeito e antes da confirmação. Um marcador de conclusão antecipado pode perder trabalho; um marcador tardio sem coordenação pode permitir duplicação. A solução pode combinar transação local, reconciliação e contratos idempotentes das dependências. Em APS, o runbook deve indicar como reconhecer trabalho já concluído antes de autorizar replay de um lote.
Uma função timer lê um blob por SDK. O timer inicia a execução; a leitura fornece dados e não constitui um segundo trigger.
Armadilhas comuns
Retry ilimitado para payload inválido; deduplicação só em memória; sucesso no log tratado como sucesso de negócio.
Tópicos relacionados: Dados, concorrência e histórico · Identidade, tokens e autorização
Define o que pode repetir e como demonstrar o efeito já concluído.
Referência: Idempotent Functions design · AZ-204 archived objectives 2026-01-14; retired 2026-07-31