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

Open
#2,008 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
csharp

Research direction

No specific files are named. Start by tracing the .NET session subscription and FIFO dispatch path, then inspect the proposed session.waitForIdle runtime contract alongside session.idle and GetEventsAsync handling. Done means a regression test shows completion waits for all preceding events, handles dropped idle notifications, surfaces failures, and supports cancellation.

Written by the indexing model from the issue text.

Description

bug waiting on response

Summary

Visual Studio can remain indefinitely in the running state after the Copilot CLI has completed a response.

The CLI verbose log shows that it forwarded the terminal, ephemeral session.idle event. The .NET SDK subscription receives the preceding events, including the final assistant.turn_end, but never receives SessionIdleEvent.

Because session.idle is ephemeral, it cannot be recovered later through GetEventsAsync(). The client therefore has no authoritative completion signal and continues waiting.

Environment

  • GitHub.Copilot.SDK: 1.0.1
  • Copilot CLI runtime: 1.0.61
  • Windows ARM64
  • Visual Studio Agent and Agent (Preview) modes

The current SDK 1.0.7 still does not expose a durable idle wait or event-dispatch flush API.

Observed behavior

The CLI log ends with:

Forwarding event ... assistant.turn_end
Forwarding event ... session.idle (ephemeral)

The .NET subscriber observes assistant.turn_end, but not session.idle. The operation remains active even though the runtime has finished.

The absence of session.idle from events.jsonl is expected because the event is ephemeral; it does not explain why the live subscriber missed it.

Why assistant.turn_end is insufficient

In multi-turn tool workflows, an intermediate assistant.turn_end can be followed immediately by another assistant.turn_start. Completion also needs to account for sub-agents, attached shells, queued messages, and follow-up notification turns.

Requested fix

Please provide an authoritative completion contract owned by the runtime/SDK, for example:

await session.WaitForIdleAsync(cancellationToken);

It should:

  1. Wait for turns, sub-agents, attached shells, queued work, and follow-up turns to settle.
  2. Resolve only when the runtime is fully idle.
  3. Ensure preceding session events have crossed the .NET SDK FIFO dispatch queue.
  4. Surface session errors and transport failures.
  5. Remain correct if the live session.idle notification is dropped.
  6. Support cancellation without leaving an orphaned waiter.

An equivalent session.waitForIdle runtime RPC combined with an SDK dispatch barrier would also work.

Regression test

Add a .NET test where a multi-turn response completes, the live session.idle notification is deliberately dropped, and the completion wait still resolves only after all preceding assistant and tool events have been delivered.

Related

  • #794 - identifies missing session.idle and silent notification drops, but its proposed fallback did not ship
  • #558 - timeout waiting for session.idle
  • #791 - serialized FIFO event dispatch in the .NET SDK
  • #927 - ephemeral events are intentionally unavailable through replay
  • #1275 - assistant.turn_end alone is not a completion signal
Dominant language
Java
Stars
10.5k
Forks
1.5k
Avg merge
1d 9h
Merged PRs (30d)
131

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/copilot-sdk

All issues in github/copilot-sdk

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.