Surviving a refresh

Ninety seconds into a two-minute answer about transferring points to an airline partner, the user hits reload. Or their phone locks and Safari discards the tab. Or they follow a link, read something, and come back.

Today the answer is gone. Not stopped, not failed — gone, with an empty composer and no evidence anything ever happened. The user asks the same question again and waits another two minutes for an answer that was already most of the way to being written.

A refresh is not a stop

Start with the one sentence that reframes the whole problem. Vercel documents its own default wiring:

“client-side aborts are treated as disconnects. Closing a tab, refreshing the page, or calling stop() only closes the current HTTP connection and should not cancel the underlying generation.”

Vercel writes the AI SDK and sells the platform this page leads to, so the scope of the claim is their wiring rather than streaming HTTP in general. Within that scope it says something useful: the answer is not lost. Your connection to it is. The generation is still happening, in a process that has no idea the reader left, and the reason the screen is empty is that nothing was holding the output anywhere except the socket you just closed.

That is the reframe. Resumability is not a recovery feature bolted onto a failure. It is what you get automatically once the stream exists somewhere other than the connection, and everything difficult about it is in that one requirement.

What the requirement actually costs

Vercel’s own documented architecture is the honest price list, and it is worth reading precisely because the vendor has every incentive to make this look cheap. The page requires Redis, a persistence layer tracking an activeStreamId per chat, two endpoints, and the resumable-stream package.

Three of those four are yours to build and operate. The package is a dependency; the durable store is infrastructure somebody has to run, the persistence layer is code somebody has to write, and the second endpoint is a route somebody has to secure. Read the ordering constraint too: the stream id has to be written before the first token, because an id that is recorded when generation finishes cannot help a client that disconnected in the middle.

Redis is Vercel’s choice, not a requirement of the problem. The constraint is a durable, queryable store keyed by a stream or run id, readable by a process other than the one that started the generation. Anything satisfying that satisfies this. What you cannot do is skip it: the documentation is explicit that the persistence layer is something you build, not something the SDK provides.

The client half

With the infrastructure in place the client side is small, which is exactly the wrong lesson to take from it. useChat returns a named resumeStream function, and Vercel’s documented pattern calls it on mount:

// Server: persist a stream id the moment generation starts, independent
// of any one HTTP connection.
// Client:
const { resumeStream } = useChat()
useEffect(() => {
  resumeStream() // attempts to reattach to an in-flight generation, if any
}, [])

Note the word attempts. There may be nothing to reattach to: the generation finished while the tab was closed, or it never started, or the id expired. Every one of those needs a rendering, and none of them is the same screen as “reattached and streaming.” A reload that silently shows nothing while a resume attempt fails is the original bug wearing a dependency.

Four behaviours, and you have to pick one

“Correct and stated” means choosing from this list on purpose, per surface:

• Lose it. The refresh discards the turn and the composer comes back empty. Cheapest, and defensible on a surface where answers are short and cheap to regenerate. It stops being defensible at two minutes.
• Replay the prefix. Show what was persisted, clearly marked as incomplete and not continuing. Honest, cheap, and useful on a surface where the partial answer has standalone value. Do not describe it as resuming.
• Reattach. Replay the prefix and continue live from the generation that never stopped. The real thing, and the one that costs the store, the id and the second endpoint.
• Restart. Throw the partial away and generate again from the top. Simple and correct, and it pays for the whole answer twice while the user watches text they have already read.

The choice is not purely a UX one, which is the point of putting it in this module. Reattach requires infrastructure the UI team does not own. Restart doubles a cost somebody is paying. Lose-it is free and gets expensive in complaints. Whoever is designing the surface has to bring the trade to the people who own the other two variables rather than picking whichever the framework did by default.

What the durable store now contains

One consequence teams meet late. Before resumability, in-flight assistant output existed only in transit and in the browser. After it, every partial answer lands in a store with a retention policy, an access control list and a backup schedule, and it is user content — for this chatbot, questions about somebody’s points balances and travel plans.

This course is not going to tell you what the retention window should be; that depends on rules it has not verified for your organisation. What it will tell you is that adding resumability adds a new store of user content, and that the people who need to know are the ones who would have found out during a review six months later. Raise it in the same conversation as the five questions above.

What this does not cover

This lesson solves one reader coming back to one run. The same stream id makes a second viewer and a mid-flight reconnect the same problem with the same answer, and Vercel’s worked example demonstrates the single-reader case rather than fanning out to two live viewers, so treat concurrency as implied by the architecture and not shown by the source. That is the two-tabs lesson in the production module.

Everything between your server and the browser that decides whether a stream arrives incrementally at all — proxies, gateways and CDNs that buffer by default — is the infrastructure-survival lesson in that same module. There is no point resuming a stream into a proxy that holds it.

The case where the connection dies and you have no durable store to reattach to is the retry lesson before this one. Correcting an answer that arrived intact and answered the wrong question is the partially-wrong-answer lesson next. And what an unread generation costs while it runs on without a reader is the abandoned-run lesson, which is where this module’s uncomfortable question finally gets asked directly.