Add an awaited terminal cancellation API for ACP prompts

Abierto
  • ¿Algo no está bien?
#1,760 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust, typescript
Área
api, backend, testing-qa

Línea de trabajo

Comienza con crates/client/src/session.rs, packages/core/src/agent-os.ts y crates/agentos-actor-plugin/src/actions/session.rs para rastrear la cancelación, los productores de prompts y los resultados terminales. Usa los escenarios listados de retraso, ignorado, permisos, herramientas, condiciones de carrera, llamadas repetidas y actor/cliente directo como pruebas de aceptación. Se considera terminado cuando ambos clientes y la acción del actor exponen paridad, se espera a la quiescence o al hard-close y se emite exactamente un resultado terminal.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

AgentOS currently exposes cancellation acknowledgement, not a reliable terminal/quiescence boundary.

When a prompt is pending, both clients resolve the local prompt and dispatch the real session/cancel in the background:

  • crates/client/src/session.rs — AgentOs::cancel_session
  • packages/core/src/agent-os.ts — AgentOs.cancelSession

The returned synthetic { via: "prompt-fallback" } result means only that cancellation was requested. It does not prove that the adapter stopped the turn, stopped emitting events, released tool/permission work, or can safely accept the next prompt.

The actor plugin also aborts its tracked prompt task before issuing cancellation in crates/agentos-actor-plugin/src/actions/session.rs. This can suppress the correlated terminal promptResult event, leaving callers without a clean completion signal.

A real Claude ACP reproduction acknowledged cancellation and appeared idle while the original turn remained active; an immediate follow-up then remained blocked for minutes. GigaCode currently compensates with a timer, an awaited session close, ACP-session recreation, and transcript handoff before reporting idle.

Proposed API

Expose an awaited terminal operation in both Rust and TypeScript, conceptually:

cancelPromptAndWait(sessionId, options?) ->
  { state: "quiescent", sessionReusable: true }
  { state: "closed", sessionReusable: false }
  { state: "timed_out", sessionReusable: false }

The exact naming and types can follow existing AgentOS conventions. If multiple in-flight turns become supported, the operation should also accept a turn/request ID.

Required semantics

  • Deliver ACP cancellation through a control/interrupt path that cannot queue behind the prompt being cancelled.
  • Do not discard the prompt producer before it publishes a terminal outcome.
  • Emit exactly one terminal prompt outcome: completed, cancelled, failed, or session closed.
  • Do not return quiescent until the old turn can no longer emit output, request permissions, run tools, or interfere with the next prompt.
  • Report whether the existing ACP session is reusable.
  • Support a bounded hard-cancel policy that closes the adapter session/process when cooperative cancellation does not quiesce.
  • Await adapter process teardown before returning closed.
  • Make repeated/concurrent cancellation calls idempotent.
  • Preserve parity between the Rust and TypeScript clients and the actor action surface.
  • Keep cancellation errors structured; do not collapse them into core/internal_error.

Acceptance tests

  • A delayed mock prompt cooperatively cancels, emits one cancelled terminal result, and the same session accepts an immediate follow-up.
  • An adapter that acknowledges but ignores cancellation reaches the deadline, is closed, and reports sessionReusable: false.
  • The hard-close path leaves no adapter process, prompt resolver, permission request, tool task, or event pump alive.
  • Cancellation while a permission request or tool call is pending settles that work before the API returns.
  • A completion racing cancellation still produces exactly one terminal result.
  • Repeated cancellation calls return a consistent result without duplicate cancellation/close operations.
  • Actor-backed and direct AgentOS clients pass the same lifecycle tests.

Outcome

Products should be able to report idle immediately after this operation returns without implementing their own cancellation timers, prompt listeners, process teardown, session recreation, or quiescence barriers.

Lenguaje dominante
Rust
Estrellas
4.8k
Forks
275
Merge medio
13 h 12 min
PR fusionados (30 d)
51

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rivet-dev/agentos

Todos los issues de rivet-dev/agentos

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.