Skip to content

fix(dotnet): handle unknown session event types gracefully#881

Open
Ron537 wants to merge 2 commits intogithub:mainfrom
Ron537:fix/dotnet-unknown-session-event-handling
Open

fix(dotnet): handle unknown session event types gracefully#881
Ron537 wants to merge 2 commits intogithub:mainfrom
Ron537:fix/dotnet-unknown-session-event-handling

Conversation

@Ron537
Copy link

@Ron537 Ron537 commented Mar 18, 2026

Summary

When the Copilot CLI introduces new session event types before the SDK is updated,
SessionEvent.FromJson() throws a JsonException (due to FailSerialization policy),
breaking both GetMessagesAsync and real-time event dispatch.

Fixes #880

Changes

  • UnknownSessionEvent — concrete fallback type preserving RawType and RawJson
  • SessionEvent.TryFromJson — public partial method that returns UnknownSessionEvent instead of throwing, with warning logging
  • GetMessagesAsync — uses TryFromJson so unknown events don't fail the entire history
  • OnSessionEvent — uses TryFromJson so unknown real-time events don't crash the RPC handler
  • 10 unit tests covering known/unknown deserialization, fallback behavior, and mixed event lists

Approach

Follows the Python SDK pattern (SessionEventType.UNKNOWN + _missing_()) — unknown events are handled gracefully by default with no opt-in parameter needed.

No generated code changes required — TryFromJson is added via partial class extension.

Add UnknownSessionEvent type and TryFromJson method so that unrecognized event types from newer CLI versions do not crash GetMessagesAsync or real-time event dispatch.
@Ron537 Ron537 requested a review from a team as a code owner March 18, 2026 09:13
@SteveSandersonMS
Copy link
Contributor

Thanks for proposing this, @Ron537!

I was chatting with @stephentoub and, while we definitely agree that we need to add forward-compatibility with unknown event types, we suspect a preferred solution is to use IgnoreUnrecognizedTypeDiscriminators on the base SessionEvent type, and make it non-abstract. This will mean that unknown event types pass through as the base type.

We don't think it's desirable to add a general UnknownSessionEvent type. If we did that, then once the event type does become known in the next SDK update, that creates a different breaking change for any code written to look for UnknownSessionEvent. Plus, exposing the raw JSON could lead people to take dependencies on internal implementation details from the JSON. So if you don't mind, we will prefer not to do that, and just go with an IgnoreUnrecognizedTypeDiscriminators-style solution.

@Ron537
Copy link
Author

Ron537 commented Mar 19, 2026

Thanks @SteveSandersonMS & @stephentoub !

Great suggestion — I've updated the PR to use IgnoreUnrecognizedTypeDiscriminators = true on the [JsonPolymorphic] attribute and made SessionEvent non-abstract with a virtual string Type => "unknown" default.

Changes are now entirely in the codegen (scripts/codegen/csharp.ts) + regenerated output — no runtime code changes needed. The previous UnknownSessionEvent / TryFromJson approach has been removed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

.NET SDK: GetMessagesAsync fails entirely when CLI returns unknown event types

2 participants