You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Remote agent host sessions often fail to open in Insiders 1.143 ("Couldn't load this conversation", and re-opening doesn't retry) #341828
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.
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.
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.
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!
Activity
Harini410 commentedon Oct 15, 2026
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!