A execução parou e por quê

Como ler por que uma execução não avança. Os status que o AutoDev usa, o motivo que ele registra a cada vez que pausa ou para, e o que continua cada um.

Leia o motivo #

Uma execução que parou registra o próprio motivo. autodev status imprime o estado, autodev report imprime o motivo ao lado dele, e o painel diz a mesma coisa em Needs you e na barra de status. autodev status imprime estas linhas:

Project: <name>
Status: <status>
Daemon: pid <n> (alive)
Current task: <task>
Iteration: <n>
Est. cost: $<n>
Heartbeat: <n>s ago
Next resume: <time>
Web: not serving
Waiting: <reason> (<n>m elapsed)

Status é um entre idle, running, rate_limited, waiting, paused, gated, awaiting_user, completed ou error. Daemon é pid <n> (alive) ou stopped. Next resume é a hora em que um limite de uso termina, ou None. Waiting aparece só enquanto o status é waiting. O heartbeat recebe (stalled?) no fim só quando o daemon está vivo, a execução está ativa e o último heartbeat tem 40 minutos ou mais.

running, rate_limited e waiting afirmam que o loop está executando. Vistos sem nenhum daemon vivo, são o resto de uma execução encerrada à força: a barra de status mostra (stopped) ao lado deles, e autodev report mostra (stale).

autodev report abre com uma linha para o motivo. Uma execução que você pausou aparece como paused by you · daemon stopped. Qualquer outra execução parada aparece como <status> · daemon stopped · <o último motivo>, onde o motivo é o último evento que encerrou algo, e uma execução viva aparece como <status> · alive. No painel, uma execução pausada ou em error sem daemon acrescenta um item em Needs you dizendo que ela não vai retomar sozinha. Uma execução que você mesmo pausou não recebe esse item, porque encerrar essa pausa é com você. O feed termina com stopped ou completed na hora em que acabou.

Você parou ou pausou #

autodev stop e o controle Stop encerram a execução na iteração atual, com o status idle e o evento Stop requested. autodev pause e o controle Pause deixam o status paused com Pause requested, e o AutoDev lembra que a pausa foi sua. Nenhuma das duas é uma falha, e nenhuma retoma sozinha.

O AutoDev mantém os dois tipos de pausa separados: uma pausa sua não é apontada como algo que precisa de você, e uma causada por um limite de segurança é, como a próxima seção mostra.

Ela terminou #

O status é completed, e o log tem All tasks resolved. O daemon já encerrou. Para dar mais trabalho a um projeto concluído, envie uma mensagem: o compositor do painel, ou autodev send "<message>", que imprime Message sent; run started. Para recomeçar com uma thread vazia, autodev new-run arquiva esta antes.

Ela atingiu um limite #

Um limite de segurança pausa a execução, e o status é paused. O motivo é um evento no log, com uma destas mensagens:

Uma execução que recomeça pausa de novo enquanto o limite continuar atingido, então aumente o limite primeiro, com autodev config set ou o destino Config, e depois continue. Todas as chaves de configuração lista as configurações.

Ela desistiu de uma chamada que falha #

Um turno que falha sem ser um limite de uso é uma falha de infraestrutura: a CLI não iniciou, não foi alcançada ou morreu. O AutoDev tenta de novo numa escala crescente, começando em um segundo e depois esperando 1, 2, 4, 8, 15 e 30 minutos, e então uma hora. Cada turno que falha registra Turn failed (infra); will retry: seguido do que a CLI disse, e cada nova tentativa registra Attempt N of 12 failed (...); trying again at <time>. Depois de 12 falhas seguidas, cerca de cinco horas, a execução pausa com Gave up after 12 failed attempts in a row, over five hours (...); run paused — resume to try again. Um turno que funciona zera a contagem.

Dois casos diferem. Quando a API do provedor não pode ser alcançada de jeito nenhum, o AutoDev trata o provedor como fora para todos que estão nele, como um limite. O evento é <provider> could not be reached; trying it again at <time>, a espera é de 1, 2, 4 e 8 minutos e depois a cada 15 minutos, não há prazo, e um participante em outro provedor segue trabalhando enquanto isso. Provedores e failover os distingue de um limite de uso.

O outro caso é um participante que continua encerrando o turno sem postar. Cada turno assim registra Turn ended without a post, e nomeia a causa provável quando consegue: a CLI recusou permissão para as ferramentas do AutoDev, a linha de comando chegou quebrada no Windows, ou a CLI não tem ferramentas de thread. No terceiro turno seguido a execução pausa com @<participant> ended 3 turns without posting; pausing instead of spending more quota — send a message to resume. Conserte primeiro a CLI do participante, já que ela vai encerrar todo turno do mesmo jeito. Nenhuma CLI de agente encontrada e CLI não autenticada cobrem as duas causas usuais.

Ela espera, não parou #

Dois status parecem uma parada e não são. O daemon está vivo, o heartbeat continua andando, e a execução segue sozinha.

• rate_limited: todos os participantes estão em um limite de uso. Next resume é a hora em que o primeiro volta, e a execução continua então. Provedores e failover diz como o turno se move nesse meio tempo.
• waiting: um participante se recusou a começar, por um motivo que Waiting imprime, como uma pessoa trabalhando na mesma pasta. O AutoDev confere de novo, em intervalos que crescem até 30 minutos, e pausa a execução com Waited ... and gave up quando a espera passa de maxWaitMin, que é 240 minutos por padrão.

Ela espera por você #

Dois status são paradas deliberadas. O AutoDev não os reinicia, e nada os retoma sozinho.

• gated: uma ação irreversível espera. Aprove ou negue no painel com Approve ou Deny, ou execute autodev approve ou autodev deny. Com o gateMode padrão, auto, o AutoDev aprova os gates que lhe são mostrados, então isso acontece quando você define gateMode como gated. Uma ação que foi aprovada e depois falhou não é tentada de novo: a execução para com Approved action failed; run halted: <action> e o status error.
• awaiting_user: a thread passou o turno para você, com @<participant> is waiting for you. O daemon encerra, e a sua próxima mensagem o inicia de novo. autodev answer é para avisos, não para isto.

Ela morreu #

error significa que a execução pausou após 5 erros de passo consecutivos, com a mensagem Pausing after 5 consecutive step errors, ou que o processo continuou morrendo: Supervised process died N times within 300s; giving up, depois de 5 reinícios em 5 minutos. Os erros de passo estão no log com suas mensagens.

Um status ativo com Daemon: stopped significa que o processo sumiu, encerrado à força ou com a máquina desligada. autodev sem comando reinicia uma execução deixada em running, waiting ou rate_limited, e autodev start reinicia o daemon seja qual for o status. O que sobrevive a um reinício diz de onde o novo daemon parte.

Continue-a #

Toda parada acima termina do mesmo jeito, em uma destas:

• Envie uma mensagem. No painel, o compositor inicia a execução de novo quando há um time montado e confiado. Num terminal, autodev send "<message>".
• Execute autodev start. Ele reinicia o daemon e limpa uma pausa. autodev resume sozinho só grava o pedido, então não reinicia um daemon que encerrou.
• Aprove ou negue um gate.
• Execute autodev restore para rebobinar o código até um checkpoint, depois de autodev stop, quando a execução saiu errada em vez de parar. Checkpoints e restauração trata disso.
• Execute autodev new-run para arquivar a thread e recomeçar.

O painel não tem botão Resume nem Retry. Lendo os logs mostra onde os motivos são gravados.

Esta página não sabe por que uma chamada de CLI falhou. O erro de passo, ou a saída da própria CLI no log, traz essa mensagem.