Se a interface reportar um erro, tente novamente? As tarefas de documentação devem primeiro distinguir quais falhas podem ser recuperadas

Tentar novamente após um erro ser relatado é uma prática comum, mas se você tentar novamente indefinidamente e indiscriminadamente, as falhas poderão ser ampliadas. Erros de permissão, inadimplência de contas, arquivos danificados e serviços temporários ocupados devem ser tratados de maneira diferente.

Este artigo é adequado para desenvolvedores e estudantes de produtos que realizam tarefas assíncronas, como tradução e conversão de documentos. Depois de ler isto, você pode primeiro categorizar as falhas e depois decidir quanto tempo esperar, quantas tentativas no máximo e quando a intervenção do usuário é necessária.

O código e o fluxo abaixo são baseados em amostras sintéticas testadas em um ambiente isolado. Eles não representam uma garantia de todos os documentos autênticos ou efeitos do produto. Guarde os originais antes de processar documentos importantes e revise-os de acordo com os limites e itens de aceitação do texto.

Como tentar novamente depois que a tarefa do documento relatar um erro? Conclusão de uma frase

Primeiro classifique a falha antes de decidir se deve tentar novamente: as falhas temporárias são limitadas e retiradas, os problemas de permissão e conta são interrompidos e entregues ao usuário, e os erros de entrada são deixados para o usuário corrigir.

Primeiro, verifique se tentar novamente resultará em tarefas duplicadas

Os tempos de castigo no POST são especialmente problemáticos. A falha do cliente em receber uma resposta não significa que o servidor não criou uma tarefa. Se a interface não possui chaves idempotentes e um mecanismo de consulta de tarefas, reenviar cegamente pode criar múltiplas tarefas de tradução.

Portanto, as estratégias de retentativa devem priorizar o acompanhamento dos contratos de interface, em vez de apenas olhar para os códigos de status HTTP.

Escreva o número de vezes e o orçamento de espera como funções puras

from enum import Enum

class Failure(Enum):
    TRANSIENT = "transient"
    AUTH = "auth"
    BILLING = "billing"
    INVALID_INPUT = "invalid_input"

def delay_for(kind, attempt, replay_safe):
    if type(attempt) is not int or attempt < 0:
        raise ValueError("invalid attempt")
    if not replay_safe or kind is not Failure.TRANSIENT:
        return None
    schedule = (1, 2, 4)
    return schedule[attempt] if attempt < len(schedule) else None

assert delay_for(Failure.TRANSIENT, 0, True) == 1
assert delay_for(Failure.TRANSIENT, 2, True) == 4
assert delay_for(Failure.TRANSIENT, 3, True) is None
assert delay_for(Failure.TRANSIENT, 0, False) is None
assert delay_for(Failure.BILLING, 0, True) is None
assert delay_for(Failure.INVALID_INPUT, 0, True) is None

Esse código só calcula o plano de retentativa, não espera nem envia solicitações. Os valores fixos de um, dois e quatro segundos são para a demonstração de síntese e não são recomendações gerais de serviço.

O ambiente de produção também precisa considerar os seguintes pontos:

• Retry-After retornado pelo servidor
• Jitter aleatório impede que múltiplas tarefas se recuperem simultaneamente
• Prazos gerais
• Quantidade limite concorrente

Se o tempo de espera solicitado pelo servidor exceder o orçamento local, a tentativa deve ser interrompida em vez de ser solicitada antecipadamente.

Tipos de erro correspondem a diferentes ações

Salvando tarefas lógicas e logs de tentativa

Cada operação do usuário corresponde a uma tarefa lógica, e pode haver múltiplas tentativas sob essa lógica. Cada tentativa registra o horário de início, a categoria de falha e o ID da tarefa remota. No final, apenas um resultado aprovado é selecionado.

A vantagem dessa abordagem é que há um registro completo ao resolver problemas de retentativa, e o número de tentativas não é contado incorretamente como o número de solicitações dos usuários.

📊 Comparação de Núcleos

A estabilidade da experiência de tradução vem de explicações claras

Ao conectar ao OmniDoc, a interface deve informar claramente os usuários sobre o status atual: se estão esperando, precisando de reautorização ou precisam verificar a conta. Não exiba todas as situações como "Gerando".

Os usuários estão dispostos a esperar por uma tarefa declarada fora de saída, mas não estão dispostos a clicar repetidamente em um botão que não oferece feedback.

Referências: Python enum.

🎯 Qual método combina com você?

Se você está esperando o serviço retomar

Use o retreat limitado, defina a contagem máxima e o tempo total de espera, e respeite oRetry-After do servidor.

Se você encontrar problemas de permissão ou de conta

Pare a retentativa automática, solicite aos usuários para reautorizar ou verifique o status da conta.

Se a estrutura do seu arquivo de entrada estiver incorreta

Peça aos usuários que reparem arquivos antes de enviar e não reenviem o mesmo arquivo.

Se a interface que você chama for POST e pode ter expirado,

Primeiro, confirme se a interface suporta chaves idempotentes ou consultas de tarefas, e então decida se deve reenviá-la.

❓ Perguntas Frequentes (FAQ)

1. Todos os erros podem ser tentados novamente diretamente?

Não, você não pode. Erros de permissão, pagamentos em excesso de conta, arquivos corrompidos e serviço temporário ocupado devem ser tratados separadamente; apenas falhas temporárias são adequadas para evitação limitada.

2. Posso repostar depois que o tempo de espera do POST acabar?

Não é recomendado repostar diretamente. A falta de resposta do cliente não significa que o servidor não tenha criado tarefas. Sem chaves de idempotência ou mecanismos de consulta de tarefas, tarefas duplicadas podem ocorrer.

3. Como o número de tentativas e os tempos de espera devem ser determinados?

Os segundos fixos de um, dois e quatro segundos são apenas para a demonstração de síntese. O ambiente de produção deve ser determinado combinando Retry-After, jitter aleatório, tempo de corte total e restrições de concorrência.

4. O número de tentativas vai afetar as estatísticas das solicitações dos usuários?

Não, basta registrar uma operação do usuário como uma tarefa lógica e cada tentativa como uma tentativa nessa tarefa.

📝 Resumo

A chave para tentar novamente não é tentar várias vezes, mas primeiro identificar o tipo de falha antes de decidir o que fazer. Falhas recuperáveis são limitadas e tentadas novamente, e questões que exigem tratamento humano são prontamente devolvidas aos usuários.

Experimente agora: Envie seu documento para começar a traduzir, preservando a formatação original