Faking latency and failure honestly

Your mock streams. It answers in four milliseconds, renders in one frame, and never fails. You demo it, and something is off in a way nobody in the room can name. The spinner never appears long enough to read. The approval step arrives before anyone has finished the sentence it interrupts. Nobody asks what happens when it breaks, because nothing in the demo suggested it could.

A prototype is a claim about what the real thing will feel like. A mock that returns instantly and always succeeds makes that claim falsely, and the falseness is invisible, because everything on screen looks correct.

Cadence is scripted, not configured

The first instinct is to reach for a delay helper and expect it to pace the stream. It will not, and being precise about why saves you an hour.

Mock Service Worker ships a delay() function with two overloads: delay(duration?: number) and delay(mode?: 'real' | 'infinite'). Called with no argument at all, MSW’s own documentation says it applies “a realistic server response time” — a random number equal to the average response time you encounter when communicating with an actual HTTP server, which the page puts at roughly 100 to 400 milliseconds. Two things about that are easy to get wrong.

• It delays one response, not a stream of chunks. The helper waits, then the resolver returns. Nothing about it spaces out the tokens inside a streamed body.
• The implicit version is switched off inside Node test runs — MSW suppresses it there, in its own words, to prevent it affecting test performance. So an argument-free delay() is slow in your dev server and instant in your tests. If you want the same behaviour in both, pass a duration or a mode explicitly.

Cadence across a stream is therefore something you write. MSW’s streaming documentation builds a response body from a ReadableStream, and the spacing between chunks is whatever gap you put between the enqueue calls:

import { http, HttpResponse, delay } from 'msw'

export const handlers = [
  http.post('/api/mock-agent', async () => {
    // Explicit, because the argument-free form is suppressed in Node tests.
    await delay(1200)
    return HttpResponse.json({ ok: true })
  })
]

// Cadence is the gap you write, not a setting you flip.
const stream = new ReadableStream({
  async start(controller) {
    for (const token of tokens) {
      controller.enqueue(new TextEncoder().encode(token))
      await new Promise((resolve) => setTimeout(resolve, 35))
    }
    controller.close()
  }
})

If you would rather not hand-roll the event framing, MSW also has an sse namespace — sse(path, ({ client }) => client.send(...)) — which the docs position as abstracting away stream management and message encoding. The pacing is still yours. Nothing in either API knows what a plausible token rate looks like, and nothing should: the rate you pick is a design decision about the surface, not a fact about a model.

A tool-call pause is a gap between two parts

This one needs no library at all, which is why it is the cheapest of the three to fake and the one most often skipped. The protocol already separates the call from its result. Arguments arrive as tool-input-start, tool-input-delta and tool-input-available. The result arrives later as tool-output-available, or as tool-output-denied if it was refused. The AI SDK’s own tool-calling documentation describes that lifecycle, and notes that the input-delta callback fires only in streaming contexts — Vercel documenting its own SDK, as always in this course.

The pause is the wait you insert between those two parts. That is the whole mechanism. What it buys you is the question a demo audience will ask and a static mock cannot answer: what is on screen while a tool is running, and can the person cancel it.

Failure has to arrive mid-run, not at the door

A mock that returns a 500 before streaming anything tests the error boundary you already have. The interesting failure is the one that arrives after the surface has committed: half a paragraph rendered, a tool call in flight, and then nothing more.

There are three honest ways to produce it.

• Emit the protocol’s own error part after several text-delta parts have already landed. This is the faithful one, because it is what a real backend does.
• Error the stream itself — controller.error(...) part-way through — which models a transport that died rather than a run that reported failure. The surface sees these differently and should.
• Return an error response from the handler, which MSW supports like any other response, for the pre-stream case. Keep it, but do not let it be your only failure.

const stream = new ReadableStream({
  async start(controller) {
    controller.enqueue(new TextEncoder().encode('partial output...'))
    await new Promise((resolve) => setTimeout(resolve, 800))
    controller.error(new Error('simulated mid-run failure'))
  }
})

The question to answer before the demo, not during it: what does the half-written message do now? Does it stay on screen, greyed and annotated? Vanish? Sit there looking finished and correct while being neither? There is no default answer, and whichever one your prototype has today, it has by accident until you have seen it happen.

What Playwright does and does not give you

If your kit already runs Playwright, the temptation is to fake latency there instead. Be precise about what its documentation actually offers. Playwright’s network and mocking pages document request interception through page.route(), with the route then fulfilled by route.fulfill(), passed through with route.continue(), or killed with route.abort(). Microsoft publishes Playwright and these pages, which is the usual caveat.

Neither of those two pages documents a delay or latency-injection primitive. Every delay recipe found while researching this lesson came from third-party blog posts wrapping route.continue() in a setTimeout promise, not from Playwright’s own documentation. State the absence at the strength it was actually established: those two pages were read and contain no such API. That is not a proof that nothing anywhere in Playwright’s documentation tree does this.

The practical reading is that Playwright’s interception is aimed at the requests a page makes during a test, and hand-rolled timing on top of it is a workaround rather than a supported feature. For a mock you want running in the dev server, in front of a person, MSW or your own route handler is the better-supported path.

What this does not cover

Every number on this page is one you invented, including the ones in the code. That is fine while the mock is obviously a mock. It stops being fine the moment the mock has been around long enough that you trust it, and the drift from the system it stands in for is no longer visible. That is the next lesson, on when the mock starts lying to you.

The approval gate appears here only as a pair of protocol parts with a pause between them. Actually wiring the human review step, and the trace view that reads the same event stream, is the lesson on wiring the trace and the gate once.