app-server: expose loaded thread status via read/list and notifications#11786
app-server: expose loaded thread status via read/list and notifications#11786euroelessar merged 9 commits intomainfrom
Conversation
|
All contributors have signed the CLA ✍️ ✅ |
|
I have read the CLA Document and I hereby sign the CLA |
euroelessar
force-pushed
the
ruslan/thread-watch
branch
from
2deee1c to
23fc32a
Compare
euroelessar
changed the title
euroelessar
force-pushed
the
ruslan/thread-watch
branch
2 times, most recently
from
386c757 to
b6a2846
Compare
Motivation - Today, a newly connected client has no direct way to determine the current runtime status of threads from read/list responses alone. - This forces clients to infer state from transient events, which can lead to stale or inconsistent UI when reconnecting or attaching late. Changes - Add `status` to `thread/read` responses. - Add `statuses` to `thread/list` responses. - Emit `thread/status/changed` notifications with `threadId` and the new status. - Track runtime status for all loaded threads and default unknown threads to `idle`. - Update protocol/docs/tests/schema fixtures for the revised API. Testing - Validated protocol API changes with automated protocol tests and regenerated schema/type fixtures. - Validated app-server behavior with unit and integration test suites, including status transitions and notifications.
euroelessar
force-pushed
the
ruslan/thread-watch
branch
from
b6a2846 to
d36ac8c
Compare
| #[serde(rename_all = "camelCase")] | ||
| #[ts(rename_all = "camelCase")] | ||
| Active { | ||
| active_flags: Vec<ThreadActiveFlag>, |
There was a problem hiding this comment.
it's not possible to be both WaitingOnApproval AND WaitingOnUserInput is it? is it possible to flatten the status to be
NotLoaded
Idle
SystemError
Running
WaitingOnApproval
WaitingOnUserInput
?
also, do we need Idle + system_error? What's that scenario?
There was a problem hiding this comment.
hm, I've read more, and I think it's indeed not possible, but only due to user input tool spec not being marked as parallel
do we want to provide the guarantee that "model is not allowed to continue executing commands to research further while user is thinking on the response" forever? or how do we make that change in backward-compatible way?
on the other note, I'm okay to decouple SystemError from Idle, it's pretty self-container and is auto-cleared on status change anyway
4 participants
Motivation
Changes
statustothread/readresponses.statusestothread/listresponses.thread/status/changednotifications withthreadIdand the new status.idle.Testing