AWS Lambda
Guia do desenvolvedor

Comportamento de repetição do AWS Lambda

A invocação da função pode resultar em um erro por vários motivos. O código pode lançar uma exceção, um tempo limite ou ficar sem memória. O tempo de execução responsável pelo código pode encontrar um erro e parar. Você pode ficar sem simultaneidade e ser limitado.

Quando ocorre um erro, o código pode ter sido executado completa ou parcialmente, ou sequer ter sido executado. Na maioria dos casos, o cliente ou o serviço que invoca a função tentará novamente se encontrar um erro. Dessa maneira, o código precisará ser capaz de processar o mesmo evento repetidamente sem efeitos indesejados. Se a função gerenciar recursos ou gravações em um banco de dados, você precisará lidar com casos em que a mesma solicitação foi feita várias vezes.

O Lambda processa novas tentativas da maneira a seguir, dependendo da origem da invocação.

  • Origens de eventos que não são baseados em fluxo – Algumas dessas origens de eventos são configuradas para invocar uma função do Lambda de forma síncrona e outras a invocam de forma assíncrona. Dessa forma, as exceções são tratadas da seguinte forma:

    • Invocação síncrona – O Lambda inclui o campo FunctionError no corpo da resposta, com detalhes sobre o erro no cabeçalho X-Amz-Function-Error. O código de status é 200 para erros de função. O Lambda só retornará códigos de status de erro se houver um problema com a solicitação, a função ou as permissões que impedem o manipulador de processar o evento. Consulte Invocar erros para obter detalhes.

      Os gatilhos de serviços da AWS podem fazer uma nova tentativa, dependendo do serviço. Se você invocar a função do Lambda diretamente do aplicativo, poderá escolher se deseja tentar novamente ou não.

    • Invocação assíncrona – Os eventos assíncronos são enfileirados antes de serem usados para invocar a função do Lambda. Se o AWS Lambda não puder processar completamente o evento, ele repetirá a invocação duas vezes com atrasos entre as repetições. Configure uma dead letter queue para a função a fim de capturar solicitações que falharam em todas as três tentativas.

  • Fontes de eventos baseadas em sondagem que são baseadas em fluxo – Consistem em Kinesis Data Streams ou DynamoDB. Quando uma invocação de função do Lambda falha, o AWS Lambda tenta processar o lote de registros com erros até o momento em que os dados expiram, o que pode demorar até sete dias.

    A exceção é tratada como um bloqueio, e o AWS Lambda não lê nenhum novo registro do estilhaço até que o lote de registros com falha expire ou seja processado com êxito. Isso garante que o AWS Lambda processe os eventos de fluxo em ordem.

  • Fontes de eventos baseadas em sondagem que não são baseadas em fluxo – Consistem em Amazon Simple Queue Service. Se você configurar uma fila do Amazon SQS como uma fonte de evento, o AWS Lambda pesquisará um lote de registros na fila e invocará a função do Lambda. Se houver falha na invocação ou ela expirar, todas as mensagens no lote serão retornadas para a fila, e cada uma estará disponível para processamento depois que o tempo limite de visibilidade expirar. (Os tempos limite de visibilidade são um período durante o qual o Amazon Simple Queue Service impede que outros consumidores recebam e processem a mensagem).

    Assim que uma invocação processar um lote com êxito, cada mensagem nesse lote será removida da fila. Quando uma mensagem não for processada com êxito, ela será descartada ou, se você tiver configurado uma Dead letter queue do Amazon SQS, as informações de falha serão direcionadas para lá, para que você possa analisá-las.

Se você não exige o processamento classificado de eventos, a vantagem de usar filas do Amazon SQS é que o AWS Lambda continua a processar novas mensagens, independentemente de uma falha na invocação de uma mensagem anterior. Em outras palavras, o processamento de novas mensagens não será bloqueado.

Para obter mais informações sobre os modos de invocação, consulte Mapeamento de origens de eventos do AWS Lambda.