fix(dotnet): recover from dropped session idle events

[hydraxman]

Summary

• make .NET SendAndWaitAsync recover when the ephemeral session.idle notification is dropped
• use the runtime's task-drain and activity RPCs as the authoritative fallback
• flush the SDK's FIFO event-dispatch queue and reject stale inactive snapshots when new events or work appear during confirmation
• preserve the existing event-only completion path for older runtimes that do not expose the fallback RPCs

Reproduction

• Before: the dropped-idle transport reproducer times out after receiving the assistant response and assistant.turn_end
• After: the same public SDK call completes after the runtime reports no active work and preceding user handlers have drained
• A second transport reproducer reactivates runtime work during the final dispatch barrier and verifies the stale inactive snapshot is not used
• A legacy-runtime reproducer returns JSON-RPC method-not-found for the fallback API and verifies a later session.idle still completes the call

Tests

• $HOME/.dotnet/dotnet test test/GitHub.Copilot.SDK.Test.csproj -f net8.0 --no-restore --filter 'FullyQualifiedName~SendAndWaitAsync_Completes_When_SessionIdle_Notification_Is_Dropped|FullyQualifiedName~SendAndWaitAsync_Preserves_Event_Completion_When_Legacy_Runtime_Lacks_Fallback_Rpcs|FullyQualifiedName~SendAndWaitAsync_DroppedIdle_Fallback_Flushes_Preceding_Event_Handlers|FullyQualifiedName~SendAndWaitAsync_DroppedIdle_Fallback_Rechecks_Activity_After_Final_Barrier' — 4 passed
• $HOME/.dotnet/dotnet test test/GitHub.Copilot.SDK.Test.csproj -f net8.0 --no-restore — 690 passed, 3 skipped
• $HOME/.dotnet/dotnet build src/GitHub.Copilot.SDK.csproj --no-restore — 0 warnings, 0 errors
• $HOME/.dotnet/dotnet format --verify-no-changes --no-restore
• git diff --check

Fixes #2008

[Copilot]

Pull request overview

Adds a resilient .NET SendAndWaitAsync fallback when ephemeral idle notifications are dropped.

Changes:

• Uses runtime task-drain and activity RPCs to confirm completion.
• Adds FIFO event-dispatch barriers and stale-activity protection.
• Adds unit and E2E regression coverage.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
dotnet/src/Session.cs	Implements runtime completion fallback and dispatch barriers.
dotnet/test/Unit/ClientSessionLifetimeTests.cs	Tests dropped-idle recovery and activity races.
dotnet/test/E2E/SendAndWaitReliabilityE2ETests.cs	Adds end-to-end reliability coverage.
test/snapshots/send_and_wait_reliability/should_complete_when_live_sessionidle_is_dropped.yaml	Provides the replay fixture.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

[SteveSandersonMS]

Thanks for the careful work here, particularly around FIFO handler completion and the activity races.

Before taking this fix, we need to establish that it matches a real failure mode. The current tests deliberately omit session.idle, but we do not yet have a real-runtime reproduction showing that a live session.idle notification can disappear while the connection remains healthy. Issue #2008 may instead involve resumed-session initialization, subscription timing, or application-level state tracking.

This PR specifically changes SendAndWaitAsync after a new turn has emitted an assistant message or assistant.turn_end. It would not address a consumer waiting for a historical idle event after resume or tracking running state through its own event subscription. Without knowing which flow is failing, the fix is too narrow to associate confidently with #2008 and risks masking the underlying problem.

A small real-runtime reproduction where:

1. the handler receives the events preceding session.idle,
2. session.idle is not received, and
3. the same connection remains operational,

would be extremely useful. It does not need to reproduce Visual Studio itself—a minimal .NET console application would be ideal. With that evidence, we could evaluate this fallback against the actual failure and determine whether it belongs in .NET, the runtime, or all SDKs.

For now, I think we should hold this PR rather than merge a substantial recovery mechanism for a simulated-but-unconfirmed failure mode.

[hydraxman]

Thanks — agreed. The current evidence proves the fallback's race behavior under a deliberately dropped notification, but it does not establish that a healthy live runtime can actually lose session.idle in this flow.

I don't have the real-runtime reproduction you need, so I won't extend or push the recovery mechanism as if #2008 confirmed this failure mode. I'll keep the PR on hold while the resumed-session/subscription path is investigated; if I can produce a minimal console case where the preceding events arrive, session.idle does not, and the same connection remains usable, I'll add that evidence before asking for another review.