Skip to content

Remote agent host sessions often fail to open in Insiders 1.143 ("Couldn't load this conversation", and re-opening doesn't retry) #341828

Description

Telemetry (agents/sessionOpen, Insiders, last 3 days) shows a jump on 1.143 builds in remote agent host opens that never bind the chat. Those opens end as timeout or cancelled, with no model bound:

Older Insiders 1.143 Insiders
Remote agent host, external 5.1% 68.8% (93 of 121 users hit)
Remote agent host, internal 7.0% 14.7% (36 of 53 users hit)
Local agent host 1.8–2.1% 2.3–2.9% (unaffected)

By build, for remote: 16d22415b6 is normal, 4c6cba1504 is at 24–64%, and 9ebdca5c15 is at 71%. Older builds stay normal over the same hours, so this is client-side, not a service change.

Likely cause: f9eda24 (#340702). It's the only commit in 16d22415b6..4c6cba1504 that changes how the Agents window loads chats.

  1. Failed loads stay stuck.
    • The error path of ChatView._loadChat now keeps _currentChatResource and shows "Couldn't load this conversation. / Retry".
    • Before, it cleared _currentChatResource, so the next setChat reloaded the chat and recovered. That next setChat came from re-clicking the session, or from ChatGroupView re-running its autorun.
    • Now every later setChat for that chat takes the !chatChanged early return and never reloads.
  2. Replacing a provider cancels loads in progress.
    • Disposing a chat session content provider registration now cancels any content resolution in progress.
    • Remote agent hosts dispose and re-register their provider when the connection's clientId changes, for example on reconnect.
    • So a load that is waiting on the remote subscription rejects with a CancellationError that did not come from the view's own token. It then ends up stuck as in (1).
    • This part is reasoned from the code, not reproduced.

Local hosts register their provider once, which would explain why only remote is affected.

Suggested fix:

  • When the user re-opens a chat whose load failed (a setChat on a chat left unbound after the failure), retry the load.
  • Treat a CancellationError that isn't from the view's own token (the provider was replaced) as a reason to retry, not as a failure.
  • Optionally, report modelBindFailed instead of letting the open time out.

I can share the dashboard queries if useful.

Activity

  1. added
    bugIssue identified by VS Code Team member as probable bug
    regressionSomething that used to work is now broken
    on Oct 15, 2026
  2. Harini410 commented on Oct 15, 2026

    @Harini410

    Hi! I’ve submitted PR #341871 to address this issue and am continuing to work through the review feedback. If you have any additional feedback or suggestions, I’d appreciate them. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

bugIssue identified by VS Code Team member as probable bugperfregressionSomething that used to work is now broken

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions