fix: tolerate unknown hook types in .NET and Go SDKs

[Copilot]

When the CLI invokes a hook type the SDK doesn't recognize (e.g. postToolUseFailure), both the .NET and Go SDKs were returning an error over JSON-RPC. The CLI treated this as a fatal condition and shut down the session — appearing as a hang to the client.

Changes

• dotnet/src/Session.cs: Default switch arm changed from throw new ArgumentException(...) to null — unknown hook types are silently ignored
• dotnet/test/HookForwardCompatibilityTests.cs: Added unit tests using an in-process fake CLI server (connected via CliUrl) covering both "hooks registered but unknown type received" and "no hooks registered" scenarios
• go/session.go: Default switch case changed from return nil, fmt.Errorf("unknown hook type: %s", ...) to return nil, nil — same behavior
• go/session_test.go: Added TestSession_HookForwardCompatibility unit tests covering both "hooks registered but unknown type received" and "no hooks registered" scenarios

Node.js already handled this correctly (returns undefined for unmapped hook types); this brings .NET and Go to parity.

[SteveSandersonMS]

@copilot Why did you add so much stuff to Go? Is a new otel dependency really needed for this tiny change? Filter this PR down to the actual minimal change.

[Copilot]

@copilot Why did you add so much stuff to Go? Is a new otel dependency really needed for this tiny change? Filter this PR down to the actual minimal change.

Those changes were picked up accidentally when the Go toolchain resolved transitive dependencies. Reverted in 2624819 — the PR now only touches dotnet/src/Session.cs, go/session.go, and go/session_test.go.

[SteveSandersonMS]

@copilot Any reason there isn't a .NET test like the Go one?

[Copilot]

Pull request overview

This PR improves forward compatibility of the .NET and Go SDKs when the Copilot CLI invokes a hook type the SDK doesn’t recognize, preventing JSON-RPC errors that can cause the CLI to terminate the session.

Changes:

• .NET: unknown hook types no longer throw; they return null (ignored).
• Go: unknown hook types no longer return an error; they return (nil, nil) (ignored).
• Go: adds a unit test to ensure unknown hook types are ignored even when other hooks are registered.

Show a summary per file

File	Description
go/session.go	Stops treating unknown hook types as errors; ignores them instead.
go/session_test.go	Adds regression coverage for forward-compatible hook dispatch behavior.
dotnet/src/Session.cs	Stops throwing on unknown hook types; returns null so the RPC call succeeds.

Copilot's findings

• Files reviewed: 3/3 changed files
• Comments generated: 0

[Copilot]

@copilot Any reason there isn't a .NET test like the Go one?

Added in 24c28e8. Since HandleHooksInvokeAsync is internal, the test uses an in-process fake CLI server (a TcpListener on a random port) connected via CliUrl. The fake server responds to ping and session.create, then calls hooks.invoke with an unknown type once the session is ready. If the SDK returns a JSON-RPC error, rpc.InvokeAsync throws RemoteRpcException and the test fails — confirming the fix is exercised.

[github-actions]

Cross-SDK Consistency Review ✅

This PR correctly fixes a forward-compatibility issue in the .NET and Go SDKs and achieves full cross-SDK parity. Here's the summary across all four implementations:

SDK	Before	After
Node.js	✅ Returns undefined for unknown hook types (via handlerMap[hookType] → undefined)	No change needed
Python	✅ Returns None for unknown hook types (via handler_map.get(hook_type) → None)	No change needed
.NET	❌ throw new ArgumentException(...)	✅ Returns null
Go	❌ return nil, fmt.Errorf(...)	✅ Returns nil, nil

All four SDKs now silently ignore unknown hook types rather than treating them as fatal errors. No additional changes are needed to maintain consistency.

Generated by SDK Consistency Review Agent for issue #1013 · ◷