feat: support goose mode in UI #1434
Conversation
yingjiehe-xyz
requested review from
baxen,
alexhancock,
wendytang and
lily-de
yingjiehe-xyz
force-pushed
the
yingjiehe/goosemode
branch
from
1989833 to
cc8b225
Compare
| @@ -274,7 +274,8 @@ impl Agent for TruncateAgent { | |||
|
|
|||
| // Wait for confirmation response through the channel | |||
| let mut rx = self.confirmation_rx.lock().await; | |||
| if let Some((req_id, confirmed)) = rx.recv().await { | |||
| // Loop the recv until we have a matched req_id due to potential duplicate messages. | |||
There was a problem hiding this comment.
could you help me understand why we need this? what are examples of duplicate messages?
There was a problem hiding this comment.
Sure, right now, the Allow tool button is not disabled after clicking, I am trying to make it happen in following PR, so the user may click allow button multiple times or click previous allow tool button
| @@ -134,7 +134,7 @@ async fn create_agent( | |||
|
|
|||
| let new_agent = AgentFactory::create(&version, provider).expect("Failed to create agent"); | |||
|
|
|||
| let mut agent = state.agent.lock().await; | |||
| let mut agent = state.agent.write().await; | |||
There was a problem hiding this comment.
How would we be able to determine whether to use 'read' vs 'write' lock here for instance?
Nothing is done with the agent past line 137, so curious how to determine that agent needed a write lock instead of read.
There was a problem hiding this comment.
I use write lock by default to avoid any missed errors. Also in some cases, like update the system prompt or add extension, we should use the write lock
Right now, the approval workflow is like in the agent reply, when we have some tool calls, we will hold here before execution and have a recv queue waiting for confirmation, in CLI, it doesn't have any issue. In UI, I had two options to implement the approval flow:
However, I found that we have the lock on reply API until the streaming is done, so both of options don't work in this case, because previous session is not done, waiting for confirmation to finish the stream, but the confirmation message is waiting for the existing stream to release the lock, then you see, deadlock....
The tweak I did is to use read write lock in AppState, I did a quick check in the repo, looks like in reply api, we don't have to use the write lock
Test:
Config
