Um pool de proxies pode transformar uma falha simples num ciclo ocupado. Escolha um endereço, falhe, escolha outro, falhe de novo. Se todos os endpoints estiverem inacessíveis porque a sua própria rede está em baixo, mudar de endereços nunca corrige a causa.

Dê à operação um orçamento antes de escolher o primeiro proxy do seu pool ou da lista de proxies gratuitos: um número finito de tentativas, esperas de conexão e leitura limitadas e um prazo para a tarefa completa. Um timeout do Requests controla o seu comportamento documentado de conexão ou leitura; por si só não limita um ciclo que continua a emitir novos pedidos.

Decida o que merece outra tentativa

  • Uma conexão de proxy recusada pode justificar tentar outro endpoint.
  • A resposta do destino precisa da sua própria interpretação. Receber um erro HTTP prova que algum caminho de pedido foi concluído.
  • Uma falha de autenticação do proxy pede verificação do endpoint e da conta, em vez de martelar as mesmas credenciais por uma lista crescente.

Guarde a exceção ou o estado original junto do registo da tentativa. Uma mensagem final contendo apenas “todos os proxies falharam” esconde se as falhas tinham sequer a mesma causa.

Verificar a saúde de cada proxy antes de cada pedido real acrescenta outro pedido e ainda assim não garante que o próximo tenha sucesso. Reutilize informação de saúde recente onde se adequar à tarefa e depois deixe a operação real relatar o seu próprio resultado.

Uma nova tentativa pode repetir o trabalho

Numa obtenção só de leitura, passar para outro proxy costuma ser mais simples do que repetir uma submissão. Se a conexão cair depois de enviar uma compra ou uma submissão de formulário, o destino pode já a ter processado. Siga o mecanismo de idempotência do serviço e as regras de nova tentativa do HTTP antes de repetir o trabalho.

Quando o orçamento se esgotar, devolva uma falha útil. Uma tarefa que para com provas é mais fácil de reparar do que uma que continua silenciosamente a rodar até alguém reparar.

Artigos relacionados