You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yeah, this could be done with a custom transport. This transport would have the weird property that the client can make an initial batch of calls to the server, but cannot make any further calls after that point, but the server can keep making calls back to the client indefinitely. So the client could make an initial call to give the server a callback to invoke on each event. The server could then hold onto that and call it many times, each generating an SSE. Note the server wouldn't be able to await the result of any callback, because the client has no way to send calls back. So the server can just make calls, and then dispose them, and that's it.
I wouldn't be all that excited about offering this as a built-in transport, because it's a pretty weird usage model, and I'd really strongly recommend just using WebSockets instead.
That said, I suppose it would also be possible to evolve the batch transport a bit so that it streams response messages rather than sending them as one big batch. That'd be a backwards-compatible change that would also accomplish roughly the same effect as the proposed SSE transport.
Activity
kumavis commentedon Sep 24, 2025
you can make a custom transport see WebSocketTransport for reference
kentonv commentedon Sep 24, 2025
Yeah, this could be done with a custom transport. This transport would have the weird property that the client can make an initial batch of calls to the server, but cannot make any further calls after that point, but the server can keep making calls back to the client indefinitely. So the client could make an initial call to give the server a callback to invoke on each event. The server could then hold onto that and call it many times, each generating an SSE. Note the server wouldn't be able to await the result of any callback, because the client has no way to send calls back. So the server can just make calls, and then dispose them, and that's it.
I wouldn't be all that excited about offering this as a built-in transport, because it's a pretty weird usage model, and I'd really strongly recommend just using WebSockets instead.
That said, I suppose it would also be possible to evolve the batch transport a bit so that it streams response messages rather than sending them as one big batch. That'd be a backwards-compatible change that would also accomplish roughly the same effect as the proposed SSE transport.