Let somebody talk to a Bot that is already working (#16)

* Let somebody talk to a Bot that is already working

Typing into a channel while the Bot had the turn did nothing. The composer took
the keystrokes and refused the send, so a person watching their coworker head
off in the wrong direction had two ways out: stop the turn and lose whatever it
had done, or wait for it to finish being wrong. Neither is what they wanted,
which was to say "no, the other one" while it was working and have that land.

A message typed mid-turn is now parked instead of dropped. It appears in the
transcript straight away as their own bubble, faded, saying Queued underneath,
with a Remove next to it; and when the turn ends everything parked runs as one
follow-up turn with the lines joined by newlines. A burst of three corrections
costs one turn, not three.

The drain is keyed on the turn being over and never asks how it ended, which is
what makes Stop a way of steering rather than a way of giving up: park a
correction, press Stop, and the correction is what runs next. There is no stop
path in the code to forget about.

The rule is one pure reducer in composer/queue.ts and is tested as one. The
state is held by ConversationView, which is the nearest thing that owns both the
composer that parks a message and the transcript that has to show it. Its
docblock says plainly what the state is worth: memory in one tab, gone on
reload, not an outbox. The affordance is drawn only while a turn is in flight,
so a reload finds no queue and shows none rather than promising to send words it
will never send.

The compose screen does not get this. It creates the channel on send and then
navigates away, so anything parked there would go down with the unmount, which
is worse than a send button that visibly will not go. Queueing is therefore an
opt-in prop and only the channel view asks for it.

* Stop letting the run decide when the turn is over

The queue drained in the middle of answers. It waits for the turn to end and read
the end of the turn off the agent, and the agent does not know: it reports the run
on the wire, and a turn that touches the browser is several runs in a row. The Bot
asks for a click, the run ends so the browser can answer it, and another run starts
carrying the answer. In every one of those gaps the agent says it is idle. OpenBot
registers every computer tool as a frontend tool, so the gaps open on ordinary work.

The view patched half of it by also watching its own send, which covered turns typed
into the composer and nothing else. A channel starts turns by two other routes — the
first message of a new channel, and a button inside a rendered component — and for
those the queue drained on the Bot's first browser action. That posted a correction
as a second turn while the first was still going, two runs racing on one thread, and
took the unanswered tool call along with it: the history repair stitches a fabricated
"produced no result" over a call that is still executing and about to produce a real
one, which is two results for one call, which providers refuse.

So the fact is now kept where every turn passes through it. `say` is the one funnel
in the channel, and it counts what it is holding: a turn from the moment somebody
asks for it until the whole thing has come back, browser actions included. That is
what the composer is told, and what the queue waits for.

Stop is counted separately, and separately on purpose. It reaches a run through the
core's abort controller, and that controller does not exist until `say` has finished
waiting for the runtime agent — as much as a second and a half on a channel that is
still joining. Drawn from the turn, a Stop button appeared in that window, aborted
nothing, and let the message go anyway; the one control the whole affordance leans on
was quietly lying. It is drawn from the run instead, and the composer takes the two
facts as two props.

Three smaller things came out of the same reading. A queue no longer drains into a
conversation that has been disabled, because a coworker deleted mid-turn takes the
channel with it and one more user turn posted into it helps nobody; the cost is that
parked words stay on screen unrun, under the notice that says why. Each parked line's
Remove button now names the sentence it would delete, so three of them in a row are
three different buttons to somebody reading by name. And the reducer no longer leans
on an argument about two components' timing to rule out an idle send meeting a
non-empty queue: it runs them in the order they were typed instead of letting the new
one jump the line.

Author: jerelvelarde

app/src/components/channels/channel-chat.tsx

@@ -141,6 +141,33 @@ export function ChannelChat({
   const [runError, setRunError] = useState<string | null>(null);
   const awaitingReply = useRef(false);
 
+  /*
+   * TWO DIFFERENT FACTS ABOUT ONE TURN, AND NEITHER OF THEM IS `agent.isRunning`.
+   *
+   * `turnsInFlight` counts what a person would call the Bot having the turn: from the moment `say`
+   * is entered until the whole thing has come back, browser actions in the middle included. It is
+   * what decides whether the next thing typed is sent or parked, and what tells the queue its wait
+   * is over.
+   *
+   * `runsInFlight` counts what Stop can actually reach: the run `copilotkit.runAgent` opens, and
+   * nothing before it. A turn can be in flight for a second and a half before that, while `say`
+   * waits for the runtime agent, and a Stop drawn in that window aborts a controller nobody has
+   * made yet.
+   *
+   * `agent.isRunning` looks like both and is neither. It reports the run on the wire, and a turn
+   * that touches the browser is several runs in a row: the Bot asks for a click, the run ENDS so
+   * the browser can answer it, and another run starts carrying the answer. The agent reports itself
+   * idle in every one of those gaps — the truth about the wire and a lie about the turn. OpenBot
+   * registers every computer tool as a frontend tool, so the gaps open on ordinary work rather than
+   * on some edge case, and anything keyed on the turn ending fires in the middle of one instead.
+   *
+   * Counters rather than booleans because nothing stops a second turn being started from a
+   * component button while the first is still going, and two overlapping turns must not have the
+   * first one to finish declare the conversation idle.
+   */
+  const [turnsInFlight, setTurnsInFlight] = useState(0);
+  const [runsInFlight, setRunsInFlight] = useState(0);
+
   /**
    * Tell the roster what was just said. Failures here must not block the conversation.
    */
@@ -159,12 +186,10 @@ export function ChannelChat({
   reportRef.current = report;
 
   /**
-   * Send a user turn through the channel, including activity reporting and history repair.
+   * Everything `say` does once it has something worth sending, split out so the counter it is
+   * wrapped in covers every way out of here, a throw included.
    */
-  const say = async (text: string, skillInstructions: string[] = []) => {
-    const trimmed = text.trim();
-    if (!trimmed) return;
-
+  const deliver = async (trimmed: string, skillInstructions: string[]) => {
     // Wait briefly for the runtime agent instance before adding the message.
     if (!isReadyRef.current) {
       await Promise.race([
@@ -211,7 +236,32 @@ export function ChannelChat({
       agent.setMessages(repaired as typeof agent.messages);
     }
 
-    await copilotkit.runAgent({ agent });
+    setRunsInFlight((count) => count + 1);
+    try {
+      await copilotkit.runAgent({ agent });
+    } finally {
+      setRunsInFlight((count) => count - 1);
+    }
+  };
+
+  /**
+   * Send a user turn through the channel, including activity reporting and history repair.
+   *
+   * Every user turn in this channel goes through here — what the composer sends, the seed from the
+   * compose screen, and a button inside a rendered component. That is what makes the counter worth
+   * keeping here rather than in the view: the view sees only the turns it started itself, and a
+   * queue that drains on the wrong one of those posts a correction into the middle of an answer.
+   */
+  const say = async (text: string, skillInstructions: string[] = []) => {
+    const trimmed = text.trim();
+    if (!trimmed) return;
+
+    setTurnsInFlight((count) => count + 1);
+    try {
+      await deliver(trimmed, skillInstructions);
+    } finally {
+      setTurnsInFlight((count) => count - 1);
+    }
   };
 
   useEffect(() => {
@@ -335,7 +385,26 @@ export function ChannelChat({
           awaitingReply.current = false;
           copilotkit.stopAgent({ agent });
         }}
-        pending={agent.isRunning}
+        /*
+         * The turn, not the run. A browser action ends one run and starts another, and telling the
+         * conversation it is idle in between is what would drain a parked correction into the
+         * middle of an answer: a second turn racing the first on one thread, with a fabricated
+         * result stitched over a tool call that is still executing.
+         */
+        pending={agent.isRunning || turnsInFlight > 0}
+        /*
+         * A channel outlives its turns, so it is the screen where waiting is worth offering. A
+         * correction typed mid-answer is held here, in this tab, and runs as one follow-up turn the
+         * moment this one is over — including when it is over because somebody pressed the button
+         * above.
+         */
+        queueWhileBusy
+        /*
+         * The run, not the turn. Stop reaches a run through the core's abort controller, and that
+         * controller does not exist until `say` has finished waiting for the runtime agent — so
+         * this is the one place the narrower fact is the honest one to draw a button from.
+         */
+        stoppable={agent.isRunning || runsInFlight > 0}
       />
     </ConversationProvider>
   );

app/src/components/channels/chat-transcript.tsx

@@ -7,16 +7,22 @@ import { Streamdown } from "streamdown";
 import { markdownComponents } from "@/lib/markdown";
 import { EASE_OUT, ENTRANCE_SECONDS } from "@/lib/motion";
 import { Bubble, BubbleContent } from "@/components/ui/bubble";
-import { MessageContent, Message as MessageRow } from "@/components/ui/message";
+import {
+  MessageContent,
+  MessageFooter,
+  Message as MessageRow,
+} from "@/components/ui/message";
 import {
   MessageScroller,
   MessageScrollerButton,
   MessageScrollerContent,
   MessageScrollerItem,
   MessageScrollerProvider,
   MessageScrollerViewport,
+  useMessageScroller,
 } from "@/components/ui/message-scroller";
 import { toVisibleChatItems } from "./chat-messages";
+import type { QueuedMessage } from "./composer";
 import { ToolLine } from "./tool-line";
 import { ToolRenderBoundary } from "./tool-boundary";
 
@@ -25,8 +31,18 @@ type ChatTranscriptProps = {
   /** Comma-separated `/` command names, used to tell a skill chip from a leading slash. */
   commandNames?: string;
   messages: ReadonlyArray<Readonly<Message>>;
+  /**
+   * Typed while the Bot had the turn, and waiting for it to finish. Empty on a screen that does not
+   * offer queueing at all.
+   */
+  queued?: readonly QueuedMessage[];
+  /** Take one back before it runs. Without it a queued line is shown but cannot be undone. */
+  onRemoveQueued?: (id: string) => void;
 };
 
+/** One shared empty array, so a screen without a queue does not hand down a new one per render. */
+const EMPTY_QUEUE: readonly QueuedMessage[] = [];
+
 /**
  * Split a person's message into the skill they invoked and the rest of what they typed.
  *
@@ -75,6 +91,102 @@ function Thinking() {
   );
 }
 
+/**
+ * Something the person said while the Bot was working, waiting its turn.
+ *
+ * IT IS DRAWN AS THEIR MESSAGE, NOT AS A NOTICE ABOUT ONE. The whole point of letting somebody type
+ * mid-turn is that they can see their words landed, and a status line saying "1 message queued"
+ * does not do that — they would still be wondering whether the sentence they typed is the sentence
+ * that will run. So it is the same bubble, in the same column, with the same wrapping, and only two
+ * things say it has not run yet: it is faded, and it says so underneath.
+ *
+ * The footer carries the taking-back too, because that is where the reader's eye already is once
+ * they have decided this was a mistake, and because a control on the bubble itself would have to
+ * hover over the words it is offering to delete.
+ */
+function Queued({
+  text,
+  onRemove,
+}: {
+  text: string;
+  onRemove?: (() => void) | undefined;
+}) {
+  return (
+    <MessageRow align="end">
+      <MessageContent>
+        <Bubble align="end" className="opacity-60" variant="muted">
+          <BubbleContent>
+            {/* Shown exactly as typed, for the same reason a sent message is. */}
+            <span className="whitespace-pre-wrap">{text}</span>
+          </BubbleContent>
+        </Bubble>
+        <MessageFooter>
+          {/*
+           * `status` rather than `alert`, matching the thinking line: a person who has just chosen
+           * to queue something is not being interrupted by the news that it is queued.
+           */}
+          <span role="status">Queued</span>
+          {onRemove ? (
+            <button
+              /*
+               * The sentence it deletes, in the name. Three parked corrections put three buttons
+               * called "Remove" in a row, and somebody reading by name alone is told what they can
+               * do and nothing about which one it would happen to. The visible word stays short
+               * because the bubble it sits under is the answer for everybody who can see it.
+               */
+              aria-label={`Remove queued message: ${text}`}
+              className="ml-2 underline underline-offset-2 hover:text-foreground focus-visible:outline-none focus-visible:ring-3 focus-visible:ring-ring/50"
+              onClick={onRemove}
+              type="button"
+            >
+              Remove
+            </button>
+          ) : null}
+        </MessageFooter>
+      </MessageContent>
+    </MessageRow>
+  );
+}
+
+/**
+ * Put the newest queued message where the person who just typed it can see it.
+ *
+ * WITHOUT THIS THE AFFORDANCE IS INVISIBLE EXACTLY WHEN IT MATTERS. The scroller holds its anchor on
+ * the turn being answered rather than following the bottom, so during a long streamed answer the
+ * transcript sits a screen or so above the end — and a line appended below it lands off screen.
+ * Measured at the point somebody would actually use this: eighty-odd pixels under the fold, with
+ * the composer emptying at the same moment. They would have watched their correction vanish.
+ *
+ * Keyed on the newest queued id rather than on the list, so it does not fire again for every chunk
+ * of the answer still streaming above it. It does fire when the bottom-most queued line is taken
+ * back, which is a scroll nobody asked for and which lands on the end of the conversation anyway,
+ * and it stays quiet on a drain, when the id goes to null.
+ *
+ * IT COSTS THE ANCHOR, AND THAT IS THE PRICE OF THE SCROLL RATHER THAN A SIDE EFFECT OF IT.
+ * `scrollToEnd` drops whatever turn the scroller was holding its position against and starts
+ * following the bottom instead, so the rest of that answer streams past under the reader rather
+ * than staying put beneath the question. Somebody who has just typed at the bottom of the
+ * conversation has asked to be at the bottom of the conversation, so following it is the reading
+ * they chose; but they chose it for the whole turn and not only for the moment, and the button
+ * back to the anchored view is the scroller's own, not ours to restore.
+ *
+ * Rendering nothing and living inside the provider is what buys access to the scroller at all; the
+ * alternative is threading a ref out through three components with no other reason to know a
+ * scroller exists.
+ */
+function ScrollNewestQueuedIntoView({ newest }: { newest: string | null }) {
+  const { scrollToEnd } = useMessageScroller();
+
+  useEffect(() => {
+    if (newest === null) {
+      return;
+    }
+    scrollToEnd();
+  }, [newest, scrollToEnd]);
+
+  return null;
+}
+
 /**
  * How many of the newest turns cascade when a channel is opened, and how far apart.
  *
@@ -341,6 +453,8 @@ export function ChatTranscript({
   busy = false,
   commandNames = "",
   messages,
+  onRemoveQueued,
+  queued = EMPTY_QUEUE,
 }: ChatTranscriptProps) {
   /*
    * NOT MEMOISED, AND THAT IS DELIBERATE. `useMemo` keyed on `messages` looks obviously right and
@@ -436,9 +550,26 @@ export function ChatTranscript({
              * the scroller to measure and anchor something that exists for a second and a half.
              */}
             {waitingOnFirstToken ? <Thinking /> : null}
+            {/*
+             * Below the thinking line, and outside the item list for the same reason it is: these
+             * are not yet turns. They have ids of their own, but they are this tab's ids and not the
+             * thread's, so handing them to the scroller would ask it to anchor on something that is
+             * about to be replaced by a message with a different id — and the replacement is the
+             * one worth scrolling to.
+             */}
+            {queued.map((message) => (
+              <Queued
+                key={message.id}
+                onRemove={
+                  onRemoveQueued ? () => onRemoveQueued(message.id) : undefined
+                }
+                text={message.text}
+              />
+            ))}
           </MessageScrollerContent>
         </MessageScrollerViewport>
         <MessageScrollerButton />
+        <ScrollNewestQueuedIntoView newest={queued.at(-1)?.id ?? null} />
       </MessageScroller>
     </MessageScrollerProvider>
   );