fix(agents): wire ask_user answering into session/pane chat - #2303
Conversation
useAnswerAskUser + AskUserAnswerProvider were only wired into GlobalAssistantView and SidebarChatTab (#2112). The shared agent-session chat pipeline (useAgentSessionChat/useAssistantSessionChat -> SessionChatView) — rendered by AgentPageView and every pane in AgentPanes — never got the same wiring, so any ask_user tool call surfaced there was permanently non-interactive: no AskUserAnswerContext provider meant useAskUserAnswerContext() returned null, which AskUserQuestionCard treats as unconditionally unanswerable. - useAgentSessionChat/useAssistantSessionChat: call useAnswerAskUser with the hook's own renderedMessages/isConversationBusy/wrapSend/ prepareSend, and a new buildBody() extracted from handleSend's body construction (shared by both the send and answer paths). Expose askUserAnswering on UseAgentSessionChatReturn. - SessionChat.tsx: wrap SessionChatView's render in AskUserAnswerProvider so both the 'page' (ChatMessagesArea) and 'console' (SidebarMessagesContent) renderers pick it up — covers AgentPageView and every AgentPanes pane (chat + assistant-in-pane).
|
Warning Review limit reached
Next review available in: 4 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 01dce22393
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex review (PR #2303, P2): AskUserAnswerProvider ignored isReadOnly, so a viewer without edit permission still saw ask_user options/Submit as interactive — attempting to answer would 403, or could actually resume a global-assistant pane despite the surface showing "View only". Gate the provider's value on isReadOnly (null when read-only, same as rendering outside a chat surface entirely) instead of passing the live askUserAnswering unconditionally.
|
@coderabbitai review |
|
@codex review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4691a5e64c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Codex review (PR #2303, P1): isConversationBusy was wired to displayIsStreaming, which is deliberately own-stream-only (it's what Stop is scoped to). When a REMOTE collaborator is streaming in the same conversation, displayIsStreaming stays false while renderedMessages filters their in-flight message out — so the conversation's last SETTLED message can still be a stale ask_user prompt from before their run started. Submitting it would call addToolResult, whose server-side per-conversation takeover aborts the collaborator's still-running generation and resumes the stale prompt. Compute a separate isConversationBusyForAskUser (displayIsStreaming OR any non-own entry in remoteStreams) and pass that to useAnswerAskUser in both session hooks, without touching displayIsStreaming itself (Stop and the streaming UI indicator stay own-stream-scoped).
|
@coderabbitai review |
✅ Action performedReview finished.
|
1 participant
Summary
ask_userquestions being permanently non-interactive in agent-session panes (AgentPanes) and inAgentPageView's session-less chat.useAnswerAskUser+AskUserAnswerProviderinto the shareduseAgentSessionChat/useAssistantSessionChat→SessionChatViewpipeline, matching howGlobalAssistantViewandSidebarChatTabalready do it.Root cause
useAnswerAskUser/useAskUserAnsweringStore(#2112) replaced the olduseAskUserAnsweringhook and fixed its answerability logic, but only got wired into two of the four chat surfaces:GlobalAssistantView.tsxandSidebarChatTab.tsx. The shared agent-session chat pipeline —useAgentSessionChat/useAssistantSessionChat→SessionChatView, rendered byAgentPageViewdirectly and by every pane inAgentPanes(PaneChat→SessionChat/AssistantSessionChat) — never got the same wiring.AskUserAnswerContextdefaults tonullwhen unwrapped (by design, so read-only/historical renderers stay non-interactive). With no provider,useAskUserAnswerContext()returnednullinsideAskUserQuestionCard, soisAnswerablewas unconditionallyfalse— everyask_usercard in an agent session or pane rendered "Waiting for a response…" forever, regardless of the tool part's actual state.Changes
useAgentSessionChat.ts/useAssistantSessionChat.ts: calluseAnswerAskUserwith the hook's ownrenderedMessages/isConversationBusy(displayIsStreaming)/setMessages/addToolResult/wrapSend/prepareSend, plus a newbuildBody()callback extracted fromhandleSend's inline body construction (now shared by the send path and the answer path — mirrors theGlobalAssistantView/SidebarChatTabpattern). Both hooks now exposeaskUserAnsweringonUseAgentSessionChatReturn.SessionChat.tsx: wrapsSessionChatView's render in<AskUserAnswerProvider value={chat.askUserAnswering}>— covers both the'page'(ChatMessagesArea) and'console'(SidebarMessagesContent) renderers, since both dispatchAskUserQuestionCardfortool-ask_userparts.Context
Found while investigating #2238 ("unblock ask_user selections in developer/machine chats"), which turned out to be fully superseded by #2112's
useAskUserAnswering→useAnswerAskUserrewrite (closed, see #2238's closing comment). While verifying that rewrite covered #2238's original bug, this wiring gap in the pane/session surfaces turned up — it's the actual live "ask_user broken in panes" bug on master today.Verification
useAgentSessionChat.test.tsanduseAssistantSessionChat.test.tseach got a case seeding a pendingask_usertool part on the last assistant message, assertingaskUserAnswering.answerableToolCallIdsincludes it, and thatsubmitAnswersdrives a realaddToolResultcall with the righttoolCallId/tool.bun run --filter web test -- src/components/agents/— 307/307 passing (22 files), including the new cases.bunx eslinton all touched files — clean.bun run --filter web typecheck— clean.