Quando o cliente relata uma falha e nossos registros dizem que nada aconteceu

Um cliente escreveu sobre um salvamento que funcionou pela metade. Ele tinha adicionado um auxiliar para gerenciar parte de uma ferramenta de agenda compartilhada para ele. O auxiliar tentou salvar alguns dados e recebeu um erro. Parte do que ele havia preenchido ficou salva, parte não, e ele acabou preenchendo o resto à mão. Parecia um problema de permissões: uma conta de auxiliar nova e uma falha parcial, um formato bem conhecido.

Nossos próprios registros não mostravam nada

A primeira coisa que conferimos foram os nossos registros internos de erro daquele período. Não havia nada. Nenhum rastro da tentativa de salvamento chegando e falhando. Em uma investigação de suporte, um registro vazio costuma ser má notícia, porque a fonte de verdade mais fácil não tem nada a dizer.

Não paramos por aí. Reproduzimos a falha usando a própria conta do auxiliar, por meio de uma ferramenta interna da equipe que permite ao suporte ver exatamente o que um cliente específico vê. O erro apareceu na hora, com direito a captura de tela. Mesmo assim, os registros daquele período continuavam vazios (Ler em inglês). Esse vazio apontou para a resposta quando paramos de tratá-lo como um buraco nas provas e passamos a tratá-lo como um fato sobre o que tinha acontecido.

Três abas, duas delas ligadas

A tela de salvamento podia ser acessada de três lugares da ferramenta, três abas mostrando visões diferentes da mesma agenda. A lógica de salvamento só reconhecia duas delas. Na terceira aba, ela caía num beco sem saída, mostrava uma mensagem genérica de “algo deu errado” e parava sem enviar nada.

Isso explicou tudo de uma vez. Os registros estavam vazios porque não havia nada para registrar. Nenhuma requisição saiu daquela tela, então não havia o que falhar do nosso lado. Também explicou o salvamento parcial que parecia problema de permissões. As edições feitas nas duas abas que funcionavam passavam normalmente. As edições feitas na terceira aba caíam no beco sem saída todas as vezes, para qualquer pessoa. Conferimos direto, e o dono da conta teve exatamente a mesma falha naquela mesma aba.

A correção

Ligamos a ação de salvar da terceira aba ao mesmo caminho que já funcionava nas outras duas. Não ajustamos o beco sem saída para falhar de um jeito um pouco mais elegante. Depois testamos ao vivo, na mesma conta e no mesmo salvamento que tinham falhado antes, e passou sem problemas. Os dados retornados bateram com um instantâneo feito logo antes da correção, então nada tinha mudado, a não ser que a requisição agora realmente era enviada.

O que o silêncio significava

Quando um cliente relata uma falha que não deixa rastro em nenhum dos seus próprios sistemas, é tentador duvidar do relato ou supor que seu controle de registros deixou algo escapar. Nenhuma das duas coisas era verdade aqui. Nossos registros estavam corretos. Eles diziam, com razão, que nada tinha acontecido do nosso lado, porque nada tinha acontecido. Uma falha que ocorre antes de a requisição ser enviada deixa silêncio, e esse silêncio nos disse para parar de olhar o que acontecia depois que a requisição chegava e começar a olhar o que impedia que ela fosse feita.