Build: Mitra Can Be Stopped and Recovers

New words in this topic, in plain English. Come back here whenever one feels fuzzy.

run()

Mitra's single function that sends a request and decides what every possible ending means for the screen.

reason

A second value next to status that says why an answer was cut: length, stalled, broken or failed.

MESSAGES

One table that turns a status and reason into a sentence for the user, so wording lives in one place.

continueFrom

The partial answer sent back with a Continue request so the model can carry on.

Watchdog

A timer that gives up on a request that has gone quiet. Mitra has one for the first token and one for silence.

Countdown

The seconds left before a rate-limited Mitra may ask again, shown on the button.

Scripted visitor

A few lines at the end of the example that press the buttons for you, so you see each situation in turn.

1. 1

   Ask your own questions

   After the scripted visitor finishes, type "busy again". The first time the word is new, so it is refused once with a one-second countdown. Then type "policy" and press Continue.

   Each situation takes a different path through run(), and the buttons that appear are the ones that make sense for that ending.

2. 2

   Remove the stall watchdog

   In the Mitra example (the last one), delete the line const first = setTimeout(...) and the body of watchdog (make it an empty function), then run and wait.

   The scripted visitor reaches the stall question and never finishes: the status stays streaming and the last log line never appears. This is what a user sees on a dead stream without a watchdog.

3. 3

   Press Send twice

   While an answer streams, type another question and press Enter.

   Nothing happens: Send is disabled and run() returns at the first line while busy. To send a new question you press Stop first, which is the control Phase 3 added.

Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.

1. 1

   The problem this solves: Mitra from Phase 2 streams an answer well when everything works. Real use is messier: people press Stop, phones lose signal, the model is busy, and a stream sometimes goes quiet. This topic joins Topics 3.1 to 3.6 into one working component, so you can see how the pieces share state instead of fighting each other.

2. 2

   Where we start. Phase 2 left Mitra with the route /api/chat (now the OpenAI-compatible stand-in), readSSE-style parsing, smooth rendering and one status variable. It could stream an answer, but it could not be stopped, could not tell a cut-off answer from a finished one, treated every failure alike, and waited forever on a silent stream.

3. 3

   One status, many endings. status now takes the values idle, waiting, streaming, done, stopped, cut, limited and error. For cut and error, a second value reason says why (length, stalled, broken, failed). One table of messages (MESSAGES) turns the pair into a sentence. The buttons are computed from the same pair: Stop while busy, Continue after a length cut-off, Try again after a break or a rate limit, Ask again after a finish or a stop.

4. 4

   One function does the work. run(question, { continueFrom }) creates a fresh AbortController, arms two watchdogs (no first token, then silence), sends the request and branches in a single place: a 429 starts the countdown, a non-OK status is a failure, finish_reason: length is a cut-off, a missing [DONE] is a broken stream, a stall is a stall, an AbortError is a Stop. The finally block clears both timers on every path.

5. 5

   Every scenario this version handles. *Stop* after some text and before any text. *Ask again* after a stop. *Length cut-off*, then *Continue* (the text is joined, not replaced). *Rate limit* with a countdown and a locked button. *Stall*: the watchdog gives up, the partial text stays, and Try again works. *Failure before any text* shows a plain message. *Double submit* is refused while busy. *Empty input* keeps Send disabled.

6. 6

   What Mitra can do now that it could not before: be stopped, say exactly how an answer ended, keep what arrived, continue a cut-off answer, wait out a rate limit and stop waiting on a dead stream. What is still missing, and the phase that adds it: it still holds one question and one answer, so there is no conversation or saved history (Phase 4); the plumbing is hand-written (Phase 5 replaces it with the AI SDK); answers are plain text, not formatted (Phase 6); no cards, tools or approvals (Phases 7 and 8); and protection against hostile content, budgets and tests come in Phases 9 to 13. The Continue join here is simple concatenation (Topic 3.2 shows the careful version).

• ↔

  One big run() is easy to read in a lesson and gets hard to test as cases grow. Phase 4 splits it, at the price of more files and a reducer to learn.

• ↔

  Showing every ending precisely helps users and support, and costs a message table and a few more branches. For a small internal tool, fewer endings may be fine; for a customer-facing assistant, spell them out.

• I can explain how status and reason together decide the message and the buttons.

• I can follow run() from the click to each of its endings.

• I can say what the stand-in server simulates and what a real provider does instead.

• I can list what Mitra cannot do yet and the phase that adds it.

• I can add a new ending without breaking the others.