Execuções em que podes confiar

Ninguém repara numa automação até ela enviar algo duas vezes

Depois todos reparam. Os quatro mecanismos desta página existem porque as falhas deste tipo de software são sempre as mesmas quatro falhas, e todas são evitáveis por conceção em vez de por cuidado.

Simula antes de publicar

Faz passar um registo real por um fluxo de trabalho desligado e lê exatamente o que teria acontecido: o caminho seguido, cada valor em cada passo, a redação de cada mensagem e o pedido que teria ido a cada sistema externo.

Nada sai do edifício. Nenhum e-mail é enviado, nenhuma fatura emitida, nenhuma cobrança tentada, nenhuma linha escrita. As chamadas externas são registadas como intenções, com o payload que teria sido enviado, para poderes ver se o mapeamento está correto antes de se tornar problema de alguém.

As simulações são a forma de responderes à pergunta que impede as pessoas de ligar uma automação: o que é que isto vai realmente fazer?

Simulação · encomenda 88 214Nada enviado

1Validar endereçoCorrespondência encontrada. Teria escrito 6 campos.
?CondiçãoEncomenda acima de 1 000 zł? Não — 289,00 zł. Caminho curto seguido.
3FaturaTeria feito POST ao sistema de faturação. Payload mostrado na íntegra.
!Apanhado aquiTaxa de IVA mapeada a partir do campo errado. Encontrada numa simulação em vez de na caixa de entrada de um contabilista.

Enviado: nadaCobrado: nada

Uma execução percorre a versão em que entrou

Publicar uma alteração num fluxo de trabalho não afeta as execuções que já lá estão. Cada execução fica fixada à versão em que começou e termina essa versão, por mais tempo que demore e por mais que reescrevas entretanto.

Assim podes reestruturar um fluxo de trabalho enquanto dez mil pessoas estão a meio dele, e cada uma delas completa o fluxo que lhe foi prometido. A alternativa — a conceção em que todo o caminho a jusante é materializado à entrada — é a razão pela qual editar uma automação em produção parece perigoso na maioria das ferramentas. Aqui é algo banal.

As novas execuções recebem a nova versão a partir do momento em que publicas. A versão em que uma execução está fica registada na própria execução, por isso uma pergunta sobre o comportamento em março tem resposta em setembro.

Editar com tudo em produçãov4 → v5

1Antes2 918 execuções em curso, todas na v4. Algumas numa espera de dois dias.
2Publicar v511:40Dois passos reordenados, uma mensagem reescrita.
3DepoisEssas 2 918 terminam na v4. Tudo o que começar a partir das 11:40 corre na v5.
§Ninguémrecebeu metade de um fluxo de trabalho e metade de outro.

Versão registada em cada execuçãoVersões antigas guardadas

Repetições que não podem enviar em duplicado

Um passo é uma função pura das suas entradas, e os seus efeitos são confirmados em conjunto com o próprio avanço da execução para o passo seguinte. Não existe uma janela em que a mensagem já tenha saído mas a execução ainda não o saiba.

Esse é todo o truque, e é uma propriedade estrutural em vez de uma promessa. Um worker morto a meio de um passo — um deploy, um crash, uma máquina que desaparece — deixa a execução exatamente onde estava. Outro worker recolhe-a e volta a executar o passo. Como o efeito e o avanço são confirmados como um só, ou ambos aconteceram ou nenhum aconteceu.

As chamadas de saída para sistemas que suportam chaves de idempotência transportam uma, derivada da execução e do passo, para que o outro lado também reconheça a repetição.

Worker morto a meio do envioRecuperado

1Passo 5 começa09:14:06Enviar o aviso de expedição.
✕O worker morre09:14:07Deploy. Nada tinha sido confirmado.
2Recolhido09:14:31Outro trabalhador encontra a execução ainda no passo 5.
✓Enviado uma vez09:14:32O cliente recebeu um e-mail, não dois.

Os efeitos são confirmados com o avançoChave de idempotência por execução e passo

Um registo escrito para uma pessoa ler

Cada execução, cada passo, o ramo que tomou e o valor que o decidiu. Tempos por passo. O pedido e a resposta de cada chamada externa, com credenciais ocultadas. A versão em que a execução estava. Onde uma execução está à espera e até quando.

Quando alguém pergunta o que aconteceu à encomenda feita no dia catorze, há uma resposta, e encontrá-la leva um minuto em vez de uma tarde a cruzar os registos de três sistemas.

As execuções que falham reúnem-se num só lugar com o motivo agrupado, por isso "quarenta e uma falhas durante a noite" resolve-se em "um fornecedor devolveu 503 durante nove minutos" em vez de quarenta e uma investigações separadas.

Durante a noite, agrupado41 falhas

1Uma causaA API do fornecedor devolveu 503 entre as 02:41 e as 02:50.
2O que aconteceuAs 41 foram repetidas; 39 tiveram sucesso na segunda tentativa.
3PendentesDuas pararam e estão à espera de uma pessoa. Ambas estão listadas com a linha que falhou.
§Não quarenta e umainvestigações. Uma, e uma decisão sobre dois registos.

Credenciais ocultadasVersão registada

O que não afirmamos

Não publicamos um valor de disponibilidade numa página de marketing, porque um número sem uma janela de medição e sem uma definição de "disponível" é decoração. Se precisares de um a nível contratual, pergunta e falaremos sobre o que podemos realmente comprometer.

Também não podemos tornar fiável a API de outra pessoa. Se um fornecedor estiver em baixo, um fluxo de trabalho que dependa dele espera, repete e eventualmente para com um motivo claro. O que podemos prometer é que a falha é visível, que não corrompe nada e que retomar não envia a mensagem uma segunda vez.

Sobre as esperas: uma execução à espera durante dois dias é um wake_at na execução, não um trabalho parado numa fila. É por isso que um fluxo de trabalho pode manter cem mil execuções numa espera de três semanas sem que isso custe nada, e por isso o número de execuções atualmente à espera não é algo de que tenhas de te preocupar.