Question/Suggestion: Avoid emitting StopEvent through `stream_events` in v2?

[enrico-stauss]

Hi,

I couldn't find prior discussions about it, so I just wanted to understand how you feel about the fact that the current implementation emits the StopEvent twice (once in stream_events and once in await handler). While this is not really an issue since I can just break out of the loop once I receive the StopEvent, I find it unintuitive that it acts as both a regular streamed event and a result.

I could imagine leveraging the result await handler to get some extra information from the workflow, maybe something that can be accumulated using callbacks or so during the workflow.run? Or alternatively, the stream_events could just omit the StopEvent? A default parameter specifying the event types that shall be skipped during streaming?

As I said, this is not really a specific question but rather thought for discussion and since I saw that you already started planning v2, I thought now would be a good time.

Cheers :)