aaif-goose / aaif-goose/goose

ACP session ID is reused after session/delete

Abierto
#11,654 0 comentarios 0 reacciones 1 asignado Reclamado por @Abhijay007 Ver en GitHub
Lenguaje dominante
Rust
Estrellas
54.2k
Forks
6.2k
Merge medio
3 d 4 h
PR fusionados (30 d)
240

Descripción

## Summary

We observed Goose returning the same session ID for two different successful `session/new` calls on the same long-lived stdio ACP connection.

## Observed sequence

1. The client calls `session/new` and receives a session ID.
2. The invocation completes.
3. The client calls `session/close` and `session/delete`, based on the capabilities advertised by Goose.
4. The client calls `session/new` again.
5. Goose may return the same session ID for the new conversation.

Goose currently derives the ID from the current maximum daily suffix in its session storage. After the highest session row is deleted, that ID may become available again.

## Interoperability concern

The ACP specification says that `session/new` must return a unique session ID identifying the conversation, but it does not clearly define whether an ID may be reused after `session/delete`.

Different ACP agent-runtime may therefore implement different ID lifetimes. A generic ACP client may reasonably retain recently used IDs to protect notification routing and session state, causing valid-looking behavior from one agent to be treated as an error.

This creates an interoperability trap for ACP client developers.

## Suggestion

Would the Goose team consider generating session IDs that are not reused for different conversations, even after `session/delete`?

Possible directions include using an opaque unique identifier or a persistent monotonic allocation mechanism.

It may also be worth clarifying the expected lifetime of session ID uniqueness in the ACP specification.

Thank you for taking a look.

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

Look at the session management code, likely in a module handling ACP sessions. Find where session IDs are generated and stored, and examine the current mechanism based on a daily suffix. Understand the session storage to modify ID generation to be globally unique and non-reusable, perhaps using a UUID or a monotonic counter. Test by creating, deleting, and recreating sessions to verify new IDs are always unique.

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

Evaluación

Stack tecnológico
rust
Área
api, backend
Tipo de issue
Error
Dificultad
3/5
Tiempo estimado
1-2 días
Estado de actividad
Activo
Claridad
Bien especificado
Aptitud para principiantes
65/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.