Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

(bug) A failed template load tells the caller to retry with a key that can never work

Aperta
  • Qualcosa non va?
#7,048 1 commento 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

  • #7116 di @lorenzozanee — chiusa senza merge

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Ferma
Stack tecnologico
fastapi, python
Ambito
api, backend

Direzione di ricerca

Start with api/oss/src/core/agent_templates/bindings.py to follow the existing template binding validation, then trace connection resolution in api/oss/src/core/sessions/starts/service.py and retry guidance in api/oss/src/apis/fastapi/agent_templates/exceptions.py. Add coverage for rejecting an unknown connection before creation and for the guidance when a load has already started; done means both cases give callers a usable, accurate path forward.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

api backend bug report

When creating an agent from a template names a model connection that does not exist, the agent, its skill, and its files are created anyway, and only the first turn fails to start. The API answers with a 503 that tells the caller to retry using the same Idempotency-Key. That retry can never succeed: fixing the problem means sending a different connection in the request body, and the same key with a changed body always answers 409 template_load_conflict instead, because the conflict check compares the whole request body against what is already stored under that key. The agent is left behind with no session attached, and canceling it in the UI and creating a new one from the same template does not replace it. It creates a second, separate agent.

Steps to reproduce

  1. Call POST /agent-templates/load with a fresh Idempotency-Key and a template package whose model connection slug does not exist in the project.
  2. The response is 503: 
    {
  "code": "template_handoff_not_durable",
  "message": "The initial session start was not durably recorded.",
  "retryable": true,
  "next_step": "Retry with the same Idempotency-Key; do not submit a new request."
}
  3. Look up the workflow that was created anyway (for example POST /workflows/query, sorted by created_at). It exists, and it has a mount, but querying its sessions (POST /sessions/query) returns zero results. It has no session and can never run a first turn.
  4. Retry POST /agent-templates/load with the same Idempotency-Key and the same broken connection slug. The response is the same 503, every time.
  5. Retry with the same Idempotency-Key, this time with the connection slug corrected to one that actually works. The response is now: 
    {
  "code": "template_load_conflict",
  "retryable": false
}
  6. In the UI, canceling this stuck agent and trying again from the same template does not resume or replace it. It creates a second, independent agent, so the first one is simply abandoned.

Expected vs actual

Expected: either the 503's retry advice actually works, so retrying with the same key eventually succeeds once the request is fixed, or the API tells the caller plainly that the key is unusable and they need to start over.

Actual: the 503 says to retry with the same key, but no request under that key can ever succeed, because the only way to fix the underlying problem is to change the body, and a changed body under the same key is rejected as a conflict. The caller has no path forward except abandoning the key and creating a duplicate agent through the UI's cancel flow.

Where it comes from

Read on release/v0.119.1. Template loading resolves the bindings a template declares (api/oss/src/core/agent_templates/bindings.py), but it does not resolve the model connection itself. That happens later, when the first turn is dispatched inside invoke_workflow_detached (api/oss/src/core/sessions/starts/service.py), after the request has already been claimed. So an unknown connection slug is not caught as a bad request. It only surfaces as a start failure, well after the agent, its skill, and its files already exist. The 503 response and its "retry with the same key" advice come from api/oss/src/apis/fastapi/agent_templates/exceptions.py.

This has been possible since agent templates first shipped first-turn creation (#6944). It is a different case from the one #7027 fixed: that fix covers a transport-level failure while sending the first turn, not a connection that never resolves in the first place.

Proposed fix

  1. Resolve the model connection while the template load request is still being validated, alongside the existing binding checks, and reject an unknown connection with a 422 before anything is created or claimed.
  2. When the service does end up rejecting an already-started template load, stop telling the caller to retry with the same key. Say plainly that the key cannot be reused, and that they need to fix the request and start over with a new one.
Lingua principale
TypeScript
Stelle
4.8k
Fork
690
Merge medio
18h 33m
PR unite (30g)
424

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Agenta-AI/agenta

Tutte le issue di Agenta-AI/agenta

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.