.NET: [Bug]: In-memory response streams can end before a synthesized terminal event is published #8884

Description

InMemoryResponsesService can finish a streaming reader without delivering the terminal event it synthesizes for completion, failure, or cancellation.

The three fallback paths in ExecuteResponseAsync assign a terminal state.Response before calling AddStreamingEvent. A reader can acquire the state lock between those operations, see no new events together with IsTerminal == true, and return false from MoveNextAsync. The terminal event is appended afterward, too late for that reader.

Expected: publishing a synthesized terminal response and its streaming event is atomic from a reader's perspective.

This concerns service-synthesized terminal events. Executor-provided terminal events already go through AddStreamingEvent.

Code Sample

The relevant interleaving is:

1. The executor finishes without a terminal event, throws, or reports cancellation.
2. The service assigns the corresponding terminal response snapshot.
3. Before the service appends the terminal event, a streaming reader takes the state lock and observes an empty event suffix and terminal state.
4. The reader ends; the service then appends the terminal event.

A controlled service-level regression holds the publication lock while the producer reaches the append, then starts a reader reentrantly. On the current implementation, MoveNextAsync returns false for all three outcomes. These cases reproduced in five consecutive runs. This is a service-level reproduction, not an HTTP/SSE timing test.

Error Messages / Stack Traces

No exception is required: the reader ends without the synthesized response.completed, response.failed, or response.cancelled event.

Package Versions

Microsoft.Agents.AI.Hosting.OpenAI, source at 2d995049b9b08949dd12bebb61236f9300c707c4. The affected .NET code is unchanged from the reproduction baseline 3a837e3272268217fcc8d588700cf6e78fc413ef.

.NET Version

.NET SDK 10.0.401 on Linux x64; affected unit tests also run on .NET 8 and 9.

Additional Context

I'll send a focused fix that keeps each terminal snapshot local until the existing AddStreamingEvent lock publishes it with the event. Regression coverage includes the three terminal outcomes, partial output, independent readers, replay, reader-cancellation isolation, and executor-provided terminal events. No public API or persistence-policy change is needed.