Resumable Streams

[SooditK]

In Streaming responses. we can have a functionality of resumable: true (or something like that) which will try to resume a stream for a particular id.

For eg: in Vercel AI SDK. you can install their package resumable-stream & give a Redis publisher & subscriber which handles the resumption.

I think in Tanstack AI Package, we can add the same functionality which handles this out of the box

[oscabriel]

A version of this that plays well with an app deployed to Cloudflare would be cool, too! Since AI SDK's implementation requires specifically a redis instance, I haven't been able use it for my CF-deployed apps.

[DiegoGBrisa]

Another use case for this: in desktop/Electron apps (and SPAs with tab navigation), the user can navigate away from the chat view while a stream is still running. When they come back, the stream connection is gone but the server may still be generating.

What we'd need is a way to reconnect useChat (or ChatClient) to an in-progress stream by ID — something like:

  const chat = useChat({
    id: 'conversation-123',
    connection: adapter,
    resumeStreamId: activeStreamId, // reconnect to in-progress stream
  })

This is different from resumable streams after a network drop — it's more about the client lifecycle not matching the stream lifecycle. The client gets destroyed (component unmount, navigation) and a new one needs to pick up where the old one left off.

Agreed that a Redis-only approach like Vercel's is limiting. A pluggable transport (similar to how ConnectionAdapter works today) would be much more flexible.

[SooditK]

something we can plug in with S2 Lite or Durable Stream would be good. If we can have our own adapter that we can host on Railway, Fly.io or even an EC2, it would be even better