Ensure unique file paths for non-file Uris #12037
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bug: microsoft/vscode-dotnettools#2151
(deliberately not marking this PR as a fix due to DevKit process)
When an active agent chat session is open, VS Code will send LSP requests for files with the
chat-editing-text-model://scheme, similar to how the left hand side of a diff view usesgit://. This causes problems during editing because we end up getting didChange messages for Uris with that scheme, and Uris with the file scheme, which means we end up with two didChanges for the same physical file.This PR expands the fix we previously had specifically for
git://Uris, to apply to any non-file Uri. It essentially ensures these documents are always in the misc files project, so we'll still be able to generally deal with them, we just won't get confused by them. As I noted in a comment, a better fix would be to stop using file paths, but instead use the Uris provided by the LSP client as the source of truth, but given the size and risk of that change (would mean Uri/DocumentUri as a key inProjectSnapshotManager) and the fact that cohosting effectively delivers this via Roslyn anyway, it didn't seem prudent or worth it for this specific issue.