A teoria da conexão caiu por terra quando comparamos com o registro do sistema

Durante semanas tivemos uma teoria: uma conexão do celular estava caindo (Ler em inglês), e isso estava matando nosso trabalho. Toda vez que acontecia, a gente concordava com a nossa própria explicação e pedia uma correção voltada para a conexão.

A correção que pedimos não era a que precisávamos. O que matava nosso trabalho não era a conexão. Eram reinicializações que nós mesmos provocávamos, no nosso próprio computador.

O que o registro do sistema dizia

Em vez de aceitar a teoria, pegamos o registro do próprio sistema e comparamos com o que realmente tinha acontecido. Duas coisas apareceram logo de cara.

O trabalho que ficou rodando durante a noite, sem ninguém conectado, sobreviveu à noite inteira sem nenhum dano. Isso descartou a conexão como causa. Se uma conexão caindo fosse a culpada, o trabalho noturno sem nada ligado a ele também deveria ter morrido. Não morreu.

O que realmente matou o trabalho foram reinicializações feitas por nós mesmos, do computador e do programa que hospedava o trabalho. Tudo ligado a esse programa morria exatamente no mesmo instante, todas as vezes. É assim que fica quando um processo pai compartilhado cai. Falhas aleatórias estariam espalhadas em horários diferentes.

Havia um segundo erro por cima do primeiro. Também tínhamos dado vários trabalhos como falhos, porque eles ficaram quietos e pararam de gerar saída nova. Quando conferimos direito, todos ainda estavam rodando normalmente. Estavam esperando, e um deles estava pausado no meio da tarefa até a gente dar o sinal para continuar.

Essa leitura errada quase nos levou à correção errada pela segunda vez. Como acreditávamos que o problema era a conexão, a primeira ideia na mesa foi uma ferramenta feita justamente para sobreviver a conexões que caem. Ela resolveria um problema que a gente não tinha.

A correção, depois de descobrir a causa

Com a causa confirmada, a correção foi pequena e específica. Criamos um jeito de passar para o celular um trabalho que já está rodando, sem perder o histórico. Se o computador realmente precisar reiniciar, voltar de onde paramos agora custa um pedido, em vez de uma reconstrução completa. Essa correção só fez sentido depois que a teoria da conexão foi descartada. Construída em torno da causa errada, não teria resolvido nada.

O que verificamos agora

Antes de dar algo como morto, conferimos se ainda está rodando, e não só se ficou quieto. Antes de nos comprometer com uma correção, olhamos o que o registro diz que causou o problema, em vez de seguir com a primeira explicação que pareceu familiar.

As reinicializações eram nossas o tempo todo. Nunca teríamos descoberto isso olhando com mais força para a conexão.