[FEATURE REQ] Full support for SSE

[XiaofeiCao]

Track Remaining SSE Work in Azure Core and typespec-java emitter

Current Status

Minimal SSE support has been merged into Azure Core and is sufficient for Search adoption.
We've merged full SSE support into Search PR with manual implementation:
#50210

A few follow-up items were intentionally deferred and should be evaluated based on feedback from Search and future consumers.

As for current situation for Search, it's:

• Push-based listener API for sync stream
• ServerSentEventStream<CustomEvent> for exposed event
• Response -> Stream conversion lives in Search implementation
• Multiple wrappers for different event types

Full design options explored in: https://gist.github.com/XiaofeiCao/43c04645e7082a4636990eef5455b95e

1. Sync Streaming API - azure-core, typespec-java

Evaluate alternatives for synchronous SSE consumption.

Current Push-based listener API:

client.retrieveStream("my-kb", request,
    new ServerSentEventListener<KnowledgeBaseRetrievalStreamEvent>() {
        @Override
        public void onEvent(
            ServerSentEvent<KnowledgeBaseRetrievalStreamEvent> event) {
            ...
        }

        @Override
        public void onError(Throwable error) {
            ...
        }

        @Override
        public void onClose() {
            ...
        }
    });

Alternative Pull-based discussed:

try (CloseableIterableStream<ServerSentEvent<T>> events = client.retrieveStream(...)) {
    for (ServerSentEvent<T> event : events) {
        ...
    }
}

Current listener approach is adopted from clientcore, as a proven working pattern.

Question:

Should we consider Pull event model(e.g. CloseableIterableStream) to align with existing Azure SDK(e.g. foundry SDK)?

P.S. An implementation proposal for CloseableIterableStream by agent:
https://github.com/Azure/azure-sdk-for-java/pull/50081/changes#diff-69c26c3732c471927fb43304a4eea9fb00005bc6e265a30db690092222590b97

2. Event Type Exposure - azure-core, typespec-java

Currently we expose ServerSentEvent<CustomEvent>, e.g. async

Flux<ServerSentEvent<KnowledgeBaseRetrievalStreamEvent>>

Question: Should we directly expose the CustomEvent itself(making ServerSentEvent implementation detail)? e.g.

Flux<KnowledgeBaseRetrievalStreamEvent>

ServerSentEvent provides retry and last-event-id, making it possible for user to resume stream if service supports this (though Search doesn't support resumable stream).

3. Runtime vs Generated Code - azure-core, typespec-java

Question: Where should Response -> SSE stream conversion live? In azure-core or generated per SDK?

We could first generate in each SDK's implementation package(similar to getLroFinalResultOrError in mgmt client implementation).

4. Event Models - typespec-java

We used Multiple wrappers for different event types

Candidates be:

• Interface-based model: https://gist.github.com/XiaofeiCao/43c04645e7082a4636990eef5455b95e#file-03-marker-design-md
• Single wrapper for all event types(OpenAI's stainless style, not optimal for Azure codegen): https://gist.github.com/XiaofeiCao/43c04645e7082a4636990eef5455b95e#file-04-service-union-design-md

Future Enhancements

Out of scope for the initial implementation:

• Reconnect support
• Last-Event-Id support
• Retry guidance
• Stream recovery scenarios