fix(agentes): a tela de teste espera o runner, e o run sai de running - #738
fix(agentes): a tela de teste espera o runner, e o run sai de running#738HigorLira wants to merge 1 commit into
Conversation
Três defeitos do mesmo fluxo, medidos numa instalação self-host.
1. Timeout do cliente (o que a pessoa vê)
O `TestPanel` chama `apiClient.post` sem `timeoutMs` e herda o
DEFAULT_TIMEOUT_MS de 10s. Mas a rota roda o MESMO runner do agente:
cinco chamadas ao provedor (stage_classifier, jailbreak_detect,
promise_semantic, o turno e o checkpoint). Medido: ~9s no caso rápido,
21s com modelo lento e 123s sob rate limit do provedor. A tela aborta,
e como AbortError não é ApiError o toast cai no ramo genérico: a
pessoa lê "Erro inesperado." sem nenhuma pista, enquanto o servidor
conclui o trabalho e loga tudo verde. O Caddyfile já reserva 320s para
esse runner em /api/internal/agents/run*; faltava a folga no cliente.
2. O run nunca sai de `running`
O update grava status 'ok'/'error', e `ai_agent_runs_status_check`
aceita ('pending','running','completed','failed','aborted','handoff').
Todo update falhava por violação de CHECK — e o retorno não era lido,
então o erro não chegava a log nenhum. Numa instalação real: 19 runs
em 'running', inclusive os que a tela reportou como concluídos.
3. event_log da publicação nunca grava
O insert em `_actions.ts` omite `entity_kind`, que é NOT NULL sem
default. A publicação funciona, mas o evento se perde com
"null value in column entity_kind violates not-null constraint".
O status do `resultPayload` ('ok'/'blocked') é o contrato da RESPOSTA e
fica como está — só o valor gravado no banco estava fora da constraint.
|
@HigorLira is attempting to deploy a commit to the rafael-maudibrasil's projects Team on Vercel. A member of the Team first needs to authorize it. |
ECC Tools / Security EvidenceCommit: Security scanner evidence required (action_required) Detected 1 security-sensitive predictive risk signal(s) without scanner evidence. Mode: enforce Findings:
Touched security-sensitive paths:
Expected evidence:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy review recommended (neutral) Detected 3 PR taxonomy bucket(s): Security Evidence, CI/CD Recommendation, Cost/Token Risk. Scanned 4 changed file(s). Roadmap taxonomy buckets: Security EvidenceSecurity-sensitive changes should carry explicit scanner, code-scanning, or focused regression evidence. Signals:
Paths:
CI/CD RecommendationCI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work. Signals:
Paths:
Cost/Token RiskAI routing, usage, and token-budget changes should include budget or usage-limit evidence. Signals:
Paths:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 4 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
Recebido, @HigorLira — obrigado por isto. Duas coisas que vão parecer erro seu e não são:
Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 4 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
1 participant
O que este PR faz
Faz a tela Testar agente parar de mostrar "Erro inesperado." em testes que funcionam, e faz o run aparecer como concluído no histórico em vez de ficar eternamente em
running.São três defeitos do mesmo fluxo, encontrados ao investigar um único sintoma numa instalação self-host.
1. O cliente desiste antes do servidor responder
TestPanel.tsxchamaapiClient.postsemtimeoutMse herda oDEFAULT_TIMEOUT_MS = 10_000. Mas a rota executa o mesmo runner de um turno real — cinco chamadas ao provedor por teste:Aos 10 segundos o navegador aborta.
AbortError/TimeoutErrornão éApiError, então ocatchcai no ramo genérico e a pessoa lê "Erro inesperado." — sem código, sem request id, sem pista. No servidor, enquanto isso, tudo conclui e loga verde.Medições em três runs consecutivos do mesmo agente: 9,2 s · 10,2 s · 11,9 s. Dois dos três estouravam o teto — a tela funcionava por sorte, a cada clique.
O
Caddyfilejá reserva 320 s para esse runner em/api/internal/agents/run*, com o comentário de que ele "pode levar até ~5min". Faltava a mesma folga no cliente.2. O run nunca sai de
runningO update grava
status: "ok"estatus: "error". A constraint aceita outra coisa:Todo update falha por violação de CHECK. E como o retorno do
.update()não é lido, o erro não chega a log nenhum. Reproduzido diretamente no banco:Efeito numa instalação real: 19 runs em
running, inclusive os que a tela reportou como concluídos. O histórico nunca reflete a realidade.Vale notar que o
statusdoresultPayload("ok"/"blocked") é o contrato da resposta HTTP e está correto — é o que a tela exibe. Só o valor gravado no banco estava fora da constraint, e este PR toca apenas esse.3. O
event_logda publicação nunca gravaO insert em
_actions.tsomiteentity_kind, que éNOT NULLsem default:A publicação funciona (o insert é
void+.then()), mas o evento de auditoria se perde em silêncio. Usei"ai_agent", seguindo o padrão dos outros inserts do repo (contact,conversation,ai_agent_run,channel_session…).Testes
app/api/v1/ai/agents/[id]/versions/[vid]/test/route.test.ts:status: "error"— ela afirmava o valor que o código gravava, não o que a tabela aceita, e por isso passava enquanto todo update falhava calado em produção."completed"deixaria o próximo valor inventado passar do mesmo jeito.Verifiquei que pegam o defeito — reintroduzindo só as duas strings no código, os dois testes falham; revertendo, voltam ao verde.
O timeout do item 1 não tem teste: seria preciso exercitar o
AbortControllerdo cliente contra um handler lento, e não encontrei precedente disso na suíte. Se vocês tiverem um padrão para isso, escrevo com prazer.Checklist (Definition of Done)
pnpm typecheckzeradopnpm lintzerado (0 errors; os 349 warnings são pré-existentes, nenhum nos arquivos tocados)pnpm lint:channelsok — nenhuma dívida novapnpm test:unit)console.logesquecido.changes/— não escrevi; sigo a orientação do template de que isso fica com vocêsSobre a suíte completa:
tests/unit/leads-import-route.test.tsfalha 11 testes namainsem este PR — confirmei comgit stash. Não mexi nesse caminho.