.NET: runtime logs forwarding session.idle, but SDK callback never delivers it #2008

Activity

1. github-actions

   added

   bug

   on Jul 16, 2026
2. github-actions commented on Jul 16, 2026

   

   github-actionsBot

   on Jul 16, 2026 – with GitHub Actions

   Contributor

   More actions

   Investigation findings

   Label applied: bug

   I investigated the reported behavior by examining the following files:

   • dotnet/src/Session.cs — event channel and SendAndWaitAsync implementation
   • dotnet/src/Client.cs — OnSessionEvent / OnSessionLifecycle RPC handlers and method registrations
   • dotnet/src/JsonRpc.cs — JSON-RPC dispatch
   • dotnet/src/Generated/SessionEvents.cs — SessionIdleEvent deserialization

   What I found

   The SDK architecture is designed to deliver session.idle reliably to live subscribers:

   1. session.idle is properly registered as a [JsonDerivedType] and will be deserialized to SessionIdleEvent.
   2. OnSessionEvent in Client.cs calls session.DispatchEvent(evt), which TryWrites it into an unbounded Channel<SessionEvent> and then ProcessEventsAsync delivers it serially to all registered handlers — no filtering or intentional dropping occurs in the SDK.
   3. SendAndWaitAsync registers its SessionIdleEvent handler before calling SendAsync, so there is no subscription race window on the SDK side.
   4. The CLI confirms it forwards the ephemeral session.idle event — yet the SDK subscriber misses it in practice on Windows ARM64.

   Root cause assessment

   This is a genuine bug. The SDK's completion contract (SendAndWaitAsync) has no fallback when the live session.idle notification is dropped in transit. Because the event is ephemeral it cannot be recovered via GetEventsAsync(), leaving the caller waiting indefinitely (until the 60 s timeout fires).

   Previous issue #794 identified this drop and proposed a fallback that was never shipped. Issue #558 tracks the resulting timeout. The combination confirms this is a known but unresolved transport reliability gap, not intentional design.

   What a fix should address

   1. Resilient idle detection: the runtime/SDK should provide a WaitForIdleAsync-style RPC call that is answered by the runtime rather than relying solely on an ephemeral push notification.
   2. Dispatch flush guarantee: callers awaiting completion need assurance that all preceding events have been delivered to FIFO handlers before the idle signal resolves.
   3. Regression test: a test that deliberately drops the live session.idle notification and verifies the completion wait still resolves (e.g., via a polled RPC fallback) would prevent recurrence.

   I have applied the bug label accordingly.

   Warning

   Firewall blocked 1 domain

   The following domain was blocked by the firewall during workflow execution:

   • awmgmcpg

   To allow these domains, add them to the network.allowed list in your workflow frontmatter:

   network:
     allowed:
       - defaults
       - "awmgmcpg"

   See Network Configuration for more information.

   Generated by Bug Handler for #2008 · 52.8 AIC · ⌖ 5.09 AIC · ⊞ 4.5K · ◷
3. SteveSandersonMS commented on Jul 28, 2026

   

   SteveSandersonMS

   on Jul 28, 2026

   Contributor

   More actions

   Thanks for reporting this, and especially for including the CLI-side event sequence. We want to ensure Visual Studio has a reliable completion contract.

   One requested requirement is:

   Remain correct if the live session.idle notification is dropped.

   The transport is intended to provide reliable, ordered event delivery. We generally cannot support individual events being unpredictably dropped: losing assistant, tool, permission, or error events could break much more than idle detection. We are not currently aware of a confirmed case where one event disappears while the connection remains healthy. If that can be reproduced, we would prioritize investigating and fixing the delivery defect itself.

   There is a separate consideration around resume: session.idle is ephemeral and is not persisted or replayed. A completed session resumed later will not receive another copy of its previous idle event. An active resumed session should receive a future idle event when its work finishes.

   Could you share a small code sample or pseudocode showing:

   • whether the session is created or resumed;
   • if resumed, whether Visual Studio expects the prior idle state or sends new work first;
   • whether it uses SendAndWaitAsync or an event subscription; and
   • the short event sequence observed by that subscription?

   For example:

   var session = await client.CreateSessionAsync(...); // or ResumeSessionAsync(...)
   session.On<SessionEvent>(evt => Log(evt.Type));
   
   await session.SendAsync(...); // or SendAndWaitAsync(...)

   If the same live subscription receives assistant.turn_end for newly sent work but not the following session.idle, that would be particularly important. A minimal console reproduction would be ideal, but stripped-down pseudocode from the Visual Studio flow is enough to begin; no wire-level trace is needed at this stage.
4. SteveSandersonMS

   added

   waiting on response

   on Jul 28, 2026