Por que o desfazer restaurou o valor antigo em vez de um novo

Uma etapa de rotina fazia três coisas numa ordem obrigatória, e quando a última falhou, deixou a conta meio consertada e escondeu o estrago da verificação criada para encontrar contas quebradas.

A etapa restaurava uma configuração, depois restaurava outra, e então executava uma ação final que concluía o trabalho. Se essa última ação falhasse, o código relatava a falha e parava. Nessa hora, as duas primeiras mudanças já tinham sido aplicadas. Algumas configurações pareciam atualizadas, como se tudo tivesse dado certo, e a peça que importava continuava faltando.

A configuração que mantinha a conta na lista de vigilância

Uma das configurações alteradas logo no começo era exatamente o que uma verificação separada, feita com regularidade, usava para encontrar contas quebradas. Então uma falha parcial deixava a bagunça e ainda tirava a conta da lista de coisas que alguém estava vigiando. O bug quebrava a conta e apagava o único sinal que avisaria que ela estava quebrada.

Por que mudar a ordem estava fora de questão

O instinto óbvio é colocar a etapa arriscada primeiro, antes de qualquer outra mudança. Isso não funcionava aqui, porque as etapas dependiam umas das outras nessa ordem. Uma configuração precisava estar no lugar antes de a ação final apontar para o registro certo. Essa mesma configuração também era o que deixava o registro visível para a verificação de rotina depois. Trocar a ordem teria substituído uma falha recuperável por um erro diferente e pior.

O que foi para o ar: um desfazer simples

A gente não criou uma nova tentativa mais elaborada nem uma rede de segurança maior. Antes de fazer qualquer mudança, o código agora registra exatamente como estavam as configurações da conta. Se a ação final falha, ele coloca essas configurações de volta como estavam, e não as redefine para um padrão novo que pareceria que nada tinha acontecido recentemente.

Essa diferença importou. Um valor com cara de novo teria zerado o relógio de quanto tempo a conta estava com problema, fazendo um problema antigo parecer recém-surgido. Restaurar o valor original verdadeiro manteve a conta visível para a mesma verificação de rotina que já sabia como encontrá-la e consertá-la. Não construímos nenhum processo novo de detecção. O que já existia só precisava receber a verdade de volta.

Mais uma coisa pequena entrou junto. Se o próprio desfazer falha, isso é dito às claras, em vez de ser engolido. Um conserto parcial que falha em silêncio pela segunda vez é o mesmo problema de novo, só que uma camada mais fundo.

O que conferir na sua própria empresa

Qualquer processo com várias etapas que pode falhar no meio tem a mesma escolha escondida. Um envio de formulário, um reembolso em várias partes e uma lista de integração de clientes se encaixam. Quando algo quebra no meio do caminho, a falha deixa um estado que as suas verificações atuais ainda reconhecem como quebrado, ou apaga em silêncio o sinal que deveria trazer uma pessoa de volta para consertar?

Veja o que o seu processo deixa para trás quando para no meio. O desfazer aqui restaurou a configuração original da própria conta porque esse valor original era o que a verificação existente lia para decidir o que contava como quebrado.