Event Handler Exception Propagation Inconsistency Across SDKs

[brunoborges]

Summary

The .NET SDK propagates exceptions thrown by event handlers, while the Node.js, Go, and Python SDKs all isolate exceptions per-handler. This behavioral inconsistency can lead to different application behavior depending on which SDK is used.

Current Behavior by SDK

SDK	Exception Isolation	Error Reporting	Handler Storage
Node.js	try/catch per handler	Silent (caught, ignored)	Set / Map
Go	defer recover() per handler	fmt.Printf to stdout	slice with mutex
Python	try/except per handler	print() to stdout	set with lock
.NET	None — exceptions propagate	N/A (caller sees exception)	HashSet

Code Evidence

Node.js — session.ts, _dispatchEvent():

for (const handler of typedHandlers) {
    try {
        handler(event as SessionEventPayload<typeof event.type>);
    } catch (_error) {
        // Handler error
    }
}

Go — session.go, dispatchEvent():

for _, handler := range handlers {
    func() {
        defer func() {
            if r := recover(); r != nil {
                fmt.Printf("Error in session event handler: %v\n", r)
            }
        }()
        handler(event)
    }()
}

Python — session.py, _dispatch_event():

for handler in handlers:
    try:
        handler(event)
    except Exception as e:
        print(f"Error in session event handler: {e}")

.NET — Session.cs, DispatchEvent():

internal void DispatchEvent(SessionEvent sessionEvent)
{
    foreach (var handler in _eventHandlers.ToArray())
    {
        handler(sessionEvent);  // No try/catch — exceptions propagate
    }
}

Impact

1. Application resilience: In the .NET SDK, a single faulty handler can prevent all subsequent handlers from receiving events, potentially breaking SendAndWaitAsync or other internal mechanisms that depend on event dispatch.

2. Cross-SDK portability: Developers porting code between SDKs may encounter different failure modes. Code that works in Node.js/Go/Python (where one bad handler does not affect others) will behave differently in .NET.

3. Multiple handler registration: The issue is especially relevant when multiple independent components register handlers on the same session — a pattern encouraged by the IDisposable/Closeable return value from On().

Suggestion

Align the .NET SDK with the other three SDKs by wrapping each handler invocation in a try/catch:

internal void DispatchEvent(SessionEvent sessionEvent)
{
    foreach (var handler in _eventHandlers.ToArray())
    {
        try
        {
            handler(sessionEvent);
        }
        catch (Exception ex)
        {
            // Log or report the error without breaking dispatch
            Console.Error.WriteLine($"Error in session event handler: {ex}");
        }
    }
}

Alternatively, if the .NET behavior is intentional, the other SDKs' silent swallowing could be reconsidered — but the majority (3 of 4) currently isolate, which seems like the safer default.

Environment

• Observed in the main branch of all four SDK implementations
• Discovered while building the community Java SDK (https://github.com/copilot-community-sdk/copilot-sdk-java)

[github-actions]

Thank you @brunoborges for this excellent and thorough issue report! 🎯

I've labeled this as:

• bug — This inconsistency can cause unexpected behavior across SDKs
• sdk/dotnet, sdk/nodejs, sdk/go, sdk/python — Affects all four SDK implementations
• priority/high — This impacts application resilience and cross-SDK portability

Your analysis is comprehensive with clear code evidence and impact assessment. The suggestion to align .NET's behavior with the other three SDKs (exception isolation per handler) makes sense given:

1. The majority pattern (3 of 4 SDKs already isolate)
2. The resilience benefits (one faulty handler doesn't break the entire event chain)
3. The multi-handler registration pattern encouraged by the disposal pattern

The team will review this and determine the best path forward — whether to align .NET with the others or standardize on a different approach across all SDKs.

AI generated by Issue Triage Agent

[SteveSandersonMS]

Thanks for reporting it. The .NET behavior is the useful one here - ignoring exceptions is always bad, and logging to console is not useful since in many cases that either won't be visible or wrecks the app behavior. We should align the others with this as the default.

We can optionally also have some way of registering an error event handler that causes us to run the callbacks in a try/catch.