Create new queued prompts list UI#11439
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
|
I'm starting a first review of this pull request. You can view the conversation on Warp. I completed the review and no human review was requested for this pull request. Comment Powered by Oz |
5428969 to
332c4c9
Compare
There was a problem hiding this comment.
Overview
This PR adds a terminal-owned queued prompt model and a new queued-prompts panel, then routes /queue and auto-queue submissions through it while leaving Cloud Mode and compact placeholders on the legacy pending-user-query UI.
Concerns
- Two active-AI-block lookup paths no longer skip legacy pending-user-query rich content, so Cloud Mode/compact placeholders can hide the real active AI block from downstream logic.
- The new test modules call
QueuedQuery::into_text(), but the PR only definestext(), so the test build will fail.
Verdict
Found: 0 critical, 4 important, 0 suggestions
Request changes
Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).
Powered by Oz
332c4c9 to
f31a7b6
Compare
| 29. Rows reflow as the dragged item crosses the midpoint of a neighboring row, making the tentative new order visible before drop. | ||
| 30. Legacy pending-user-query placeholders for Cloud Mode, `/compact-and`, and `/fork-and-compact` are outside this panel, so they do not participate in drag-to-reorder. | ||
| ### Sequential firing | ||
| 31. When the active conversation reaches `FinishReason::Complete`, the first prompt in the queue is removed and submitted as the next user query in the same conversation, routed through the normal submission path so slash, skill, and session-sharing paths are handled correctly. |
There was a problem hiding this comment.
what happens if this is emitted while there's an active drag-to-reorder?
There was a problem hiding this comment.
If a different row is removed, the drag just continues and we re-compute the dragged item's position, so it's robust to changes there.
If the row that you're dragging is removed, and the row is currently in the first position, then the item would just disappear and be sent.
if you take row 1, drag it below row 2, and then the prompt auto-fires while you're dragging, row 2 will be correctly auto-fired even if you haven't released yet.
I can clarify the spec w/ all of these variants
| 32. While that newly-fired prompt is mid-exchange, the rest of the queue stays intact, the panel updates the count to `<N-1> queued`, and additional prompts can still be queued at the tail. | ||
| 33. The cycle continues until either the queue is empty or one of the abort conditions in (34) fires. | ||
| ### Cancellation and error handling | ||
| 34. When the active conversation finishes for any non-`Complete` reason — `Error`, `Cancelled`, `CancelledDuringRequestedCommandExecution` — auto-fire pauses immediately. The queue is not flushed. |
There was a problem hiding this comment.
we should see how this feels in dev but I'm pretty sure that claude code auto-sends the next queued propmt on cancel
There was a problem hiding this comment.
hmm, that's interesting. I kind of think we should follow claude semantics given it's what people will expect, so I might just change this to send on cancel
| `TerminalView::new` constructs one `QueuedQueryModel` per terminal view and hands that model to the input and queued-prompts panel (`app/src/terminal/view.rs (3707-4370)`). The model is terminal-owned because the panel and input are terminal-owned UI, but its rows are keyed by `AIConversationId` so switching conversations hides or reveals the correct queue without folding queue data into `TerminalView` itself. `BlocklistAIHistoryModel` remains responsible for conversation history only; queue cleanup reacts to its terminal-scoped events from `TerminalView`. | ||
|
|
||
| `QueuedQueryModel` is the source of truth for regular queued prompts (`app/src/ai/blocklist/queued_query.rs (90-365)`): | ||
| - `queues: HashMap<AIConversationId, Vec<QueuedQuery>>` stores FIFO queue contents per conversation. |
There was a problem hiding this comment.
do we actually need to store multiple queues per terminal view - in theory this lets you preserve a queue of messages across agent view enter/exit boundaries in the same terminal view yea?
But the queue is still terminal view scoped, so if you queued 3 messages in one terminal pane while the conversation was paused, then restored in another pane, it wouldn't have the queue?
Maybe this model shoudl be a singleton? Or queuing should be explicitly considered transient state in a given agent view?
Not blocking but just calling out
There was a problem hiding this comment.
Good call, I was just reviewing this PR and noticed that this map is unnecessary. Refactoring now so that it's just one list per view.
I think a singleton would maybe also make sense if we wanted the queue to be persistent across exiting and re-entering an agent view? But I think we should keep it simple for now and just consider queued prompts transient state in an open agent view
2b9f553 to
7c923bb
Compare
7c923bb to
4a0343f
Compare
4a0343f to
e17fec3
Compare

Description
This PR adds a new queued prompt panel, which allows for multiple queued prompts at a time, queued prompt editing, queued prompt re-arranging, and allows you to collapse your queued prompts when you don't want to look at them.
In this PR, I only update it so that direct prompt queueing uses this new UI, keeping cloud conversation setup using the old queued prompt UI. I think cloud conversation setup should use the new UI, but that's a separate workstream (that should maybe be feature flagged), so I think it deserves its own PR.
As is, the new UI is not feature flagged, as queued prompts as a whole are still in dogfood.
This is a pretty large PR, but I go into solid detail about the architecture and product decisions in the tech and product specs.
Implements APP-4563
Testing
./script/runScreenshots / Videos
https://www.loom.com/share/2689f5f8e12d4acabd14e6c3fa70c73e
Agent Mode