ACP session ID is reused after session/delete
- Ngôn ngữ chính
- Rust
- Star
- 54.2k
- Fork
- 6.2k
- Merge trung bình
- 3 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 240
Mô tả
## 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.
Hướng dẫn đóng góp
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- rust
- Lĩnh vực
- api, backend
- Loại issue
- Lỗi
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức phù hợp với người mới
- 65/100