[FEATURE REQ] Expose raw payload on UnknownResponseStreamEvent for safe downstream handling

[wmmihaa]

Describe the feature or improvement you are requesting

Please add a supported way to access the underlying payload/details of UnknownResponseStreamEvent (for example, event type and event-specific fields) without relying on reflection or internal members.

Today, dependent libraries can receive UnknownResponseStreamEvent during streaming when new or service-specific event types are returned, but they cannot reliably inspect the payload to route behavior. This makes it difficult to safely support forward-compatible scenarios like OAuth consent and other extension events.

This is important because ecosystem libraries that build on openai-dotnet (such as Azure.AI.Projects and Azure.AI.Extensions.OpenAI) need to surface these events to app developers in a typed or semi-typed way. If the payload is not publicly accessible, downstream libraries are forced into brittle workarounds, and users lose visibility into events that are critical for flow control (e.g., consent prompts, continuation logic, status transitions).
A stable, public access pattern for unknown event payloads would:

• Improve forward compatibility when new event kinds are introduced
• Reduce reflection/internal-access hacks in dependent SDKs
• Let downstream libraries expose meaningful diagnostics and user actions
• Make streaming integrations more robust across OpenAI and extension scenarios

Additional context

Related PR: #1078

That PR makes UnknownResponseStreamEvent and its Kind information accessible, which helps downstream SDKs start recognizing unknown event kinds. A follow-up enhancement to expose the full event payload in a supported/public way would complete the scenario for dependent libraries that must surface and act on unknown stream events.

I recently
Even if oauth_consent_request is not part of the official OpenAI spec, PR #1078 is still valuable and aligned with openai-dotnet’s role as a foundational client library. The change in #1078 does not add Azure-specific types or behavior to the SDK; it only makes unknown stream events inspectable in a supported way (UnknownResponseStreamEvent + Kind). That is a general forward-compatibility improvement for any non-modeled stream event, regardless of source.

In other words, #1078 is infrastructure, not feature coupling. It enables downstream libraries (like Azure.AI.Extensions.OpenAI / Azure.AI.Projects) to implement extension-specific flows such as oauth_consent_request outside openai-dotnet, while keeping openai-dotnet itself spec-focused and neutral. Without this capability, downstream SDKs must rely on brittle reflection/internal access, which is fragile and hard to maintain. With #1078, extension handling remains properly layered: base SDK stays generic, dependent SDKs own extension semantics.

I'm pitching in @nick863 as this relates to Azure/azure-sdk-for-net#57414

[jsquire]

@joseharriaga: I think this aligns with the discussion around exposing the Unknown variants of tools, events, etc., and providing a means to extend and construct directly via BinaryData. Would you please take a look and offer thoughts?

[jsquire]

Hi @wmmihaa. Thank you for reaching out and for your request. There have been internal discussions around the high-level concept associated with your request and, generally, we're in agreement that the ability to directly create/extend the unknown types is something that we'd like to provide. The exact design is not something that we've yet locked down. I've asked the owner of the feature to offer thoughts here and to guide the PR feedback.