Falhas e retentativas
O que cada etapa declara sobre a própria falha, quais são os padrões antes de você declarar qualquer coisa, e por que a falha é um estado previsto.
Uma API fica fora do ar, um contato some no meio de uma coleta, uma aprovação passa dois dias sem resposta. Nada disso é excepcional, é terça-feira, e por isso toda etapa que pode não terminar declara na própria configuração o que fazer com a própria falha.
São três declarações, no grupo Segurança de cada etapa: se insiste, quanto espera, e o que faz ao desistir.
Os padrões
Vale começar por eles, porque valem enquanto você não disser o contrário e porque a maioria dos procedimentos vai ao ar sem que ninguém os tenha revisto.
| Etapas de Dados | Etapas de Ação | |
|---|---|---|
| Retentativa | ligada, 3 tentativas | ligada, 3 tentativas, exponencial a partir de 15s |
| Espera | 3 horas | 5 minutos |
| Ao desistir | encerra o procedimento | encerra o procedimento |
Duas coisas aqui costumam surpreender, e as duas são deliberadas. A espera padrão de uma coleta é de três horas e não de sete dias, porque sete dias é o teto do que você pode declarar e não o que acontece por omissão, então um processo que legitimamente espera o contato voltar amanhã precisa dizer isso. E o desfecho padrão é encerrar e não escalar, porque a plataforma prefere fechar um processo que não pôde continuar a acumular conversas penduradas numa fila que ninguém pediu.
Retentativa
Diz se a plataforma tenta de novo e quantas vezes, até cinco, e é o tratamento para a falha que passa sozinha, como uma indisponibilidade momentânea, um limite de taxa ou um contato que não viu a mensagem.
Nas etapas de Ação ela tem dois parâmetros a mais, porque insistir contra um sistema tem etiqueta: a estratégia, em que exponencial dobra o intervalo a cada tentativa e linear mantém o mesmo, e o intervalo, que diz quanto esperar antes de tentar de novo. Exponencial é o padrão certo para quase tudo, já que um sistema sobrecarregado não melhora porque você insistiu mais rápido.
Insistir contra uma ação que já produziu efeito é seguro na medida em que a sua API respeite a chave de idempotência que a plataforma envia em toda chamada, descrita em Ações.
Prazo
Quanto tempo a etapa espera antes de desistir, com um teto que depende da natureza dela:
| Natureza | Espera por | Prazo máximo |
|---|---|---|
| Dados | uma pessoa responder | 7 dias |
| Ação | um sistema responder | 15 minutos |
A diferença não é arbitrária, porque uma pessoa pode responder amanhã e a espera é normal, enquanto uma API que não respondeu em quinze minutos não vai responder.
Desfecho
O que acontece quando a etapa desiste, em quatro opções, e a escolha é uma decisão de negócio e não de engenharia:
| Desfecho | O que acontece | Quando é a escolha certa |
|---|---|---|
| Escalar para humano | a conversa vai para uma pessoa, com o contexto reunido | a etapa era necessária e alguém precisa resolver |
| Executar procedimento | outro procedimento assume | existe um caminho alternativo desenhado |
| Encerrar | o procedimento termina ali | o processo perde o sentido sem aquela etapa |
| Pular | a execução segue sem o resultado | a etapa era desejável, não obrigatória |
Pular é a opção que exige mais cuidado, porque ela só é segura quando as etapas seguintes funcionam sem aquele valor. Se alguma delas usa o valor em uma Condição, pular transforma uma falha silenciosa em um caminho errado, que é a pior das duas situações, e nesse caso o desfecho honesto é escalar.
Por que a declaração fica na etapa
Poderia haver uma política única para o procedimento inteiro, e não há de propósito, porque as etapas falham por motivos diferentes e merecem respostas diferentes.
Na mesma devolução, a consulta ao prazo pode ser pulada, já que quem aprova decide sem ela, mas a emissão do rótulo não pode, porque se ela falha alguém precisa saber, uma vez que ficou gente esperando um arquivo que nunca vai chegar. Uma política única obrigaria a tratar as duas como a mesma coisa, e a resposta certa para uma seria a errada para a outra.
O que o contato vê
Nada disso vaza como erro técnico. Enquanto a plataforma tenta de novo, o agente segue disponível, e quando um desfecho é acionado o que se percebe do outro lado é apenas o que aquele desfecho produz: uma pessoa assumindo, outro caminho começando, ou o processo se encerrando.
Ninguém recebe um código de erro e, mais importante, ninguém recebe uma resposta inventada para tampar o buraco. O erro degrada para "vou verificar", nunca para uma mentira confiante, que é a mesma regra a governar a plataforma inteira e que na falha é onde mais importa.