# Compreender o comportamento de novas tentativas no Lambda
<a name="invocation-retries"></a>

Ao invocar um função diretamente, você determinará a estratégia para manipular erros relacionados ao código da função. O Lambda não repete automaticamente esses tipos de erros por você. Para tentar novamente, você pode invocar a função manualmente mais uma vez, enviar o evento com falha para uma fila de depuração ou ignorá-lo. O código de sua função pode ter sido executado completa ou parcialmente, ou nem ter sido executado. Se você tentar novamente, certifique-se de que o código de sua função pode lidar com o mesmo evento várias vezes sem duplicar transações nem ter efeitos colaterais indesejados.

Ao invocar um função indiretamente, você deve estar ciente do comportamento de novas tentativas do invocador e dos serviços que podem interagir com a solicitação no processo. Isso inclui as seguintes situações.
+ **Asynchronous Invocation** (Chamada assíncrona): o Lambda faz duas novas tentativas de erros de função. Se a função não tiver capacidade suficiente para lidar com todas as solicitações recebidas, os eventos poderão ter que aguardar na fila durante horas ou dias até serem enviados para a função. Você pode configurar uma fila de mensagens mortas na função para registrar eventos que não foram processadas com êxito. Para ter mais informações, consulte [Adicionar uma fila de mensagens não entregues](invocation-async-retain-records.md#invocation-dlq).
+ **Event source mappings** (Mapeamento da fonte do evento): mapeamentos da fonte do evento que leem das transmissões repetem todo o lote de itens. Os erros repetidos bloqueiam o processamento do estilhaço afetado até o erro ser resolvido ou os itens expirarem. Para detectar estilhaços interrompidos, é possível monitorar a métrica [Iterator Age (Idade do iterador)](monitoring-metrics.md).

  Para mapeamentos da fonte do evento que leem de uma fila, você mesmo determina o intervalo de tempo entre repetições e o destino de eventos falhos. Para fazer isso, configure o tempo limite de visibilidade e a política de redirecionamento na fila de origem. Para obter mais informações, consulte [Como o Lambda processa registros de origens de eventos baseadas em fluxos e filas](invocation-eventsourcemapping.md) e os tópicos específicos do serviço em [Invocando o Lambda com eventos de outros serviços da AWS](lambda-services.md).
+ **Serviços da AWS**: os serviços da AWS podem chamar uma função [de maneira síncrona](invocation-sync.md) ou assíncrona. Para chamada síncrona, o serviço decide se deve tentar novamente. Por exemplo, as operações em lote do Amazon S3 tentam novamente a operação se a função Lambda retornar um código de resposta `TemporaryFailure`. Os serviços que usam proxy em solicitações de um usuário ou cliente de upstream podem ter uma estratégia de repetição ou retransmitir a resposta de erro de volta para o solicitante. Por exemplo, o API Gateway sempre retransmite a resposta de erro de volta para o solicitante. 

  Para a invocação assíncrona, a lógica de repetição de tentativas é a mesma, independentemente da origem da invocação. Por padrão, o Lambda tenta novamente uma invocação assíncrona até duas vezes. Para ter mais informações, consulte [Como o Lambda lida com erros e novas tentativas com invocação assíncrona](invocation-async-error-handling.md).
+ **Other Accounts and Clients** (Outras contas e clientes): ao conceder acesso a outras contas, você pode usar as [políticas baseadas em recursos](access-control-resource-based.md) para restringir os serviços ou recursos que eles podem configurar para chamar sua função. Para evitar que a função fique sobrecarregada, considere colocar uma camada de API na frente da função com o [Amazon API Gateway](services-apigateway.md).

Para ajudar você a lidar com erros em aplicações do Lambda, o Lambda se integra com serviços como o Amazon CloudWatch e o AWS X-Ray. Você pode usar um conjunto de logs, métricas, alarmes e rastreamento do para detectar e identificar rapidamente os problemas no código da função, na API ou em outros recursos compatíveis com sua aplicação. Para ter mais informações, consulte [Monitoramento, depuração e solução de problemas das funções do Lambda](lambda-monitoring.md).