sourceUri passed into commands is stale and out of date after file has been renamed

[jeffb-sfdc]

Does this issue occur when all extensions are disabled?: N/A since this is an issue with extensions and the APIs.

• VS Code Version: 1.68.1
• OS Version: OSX 12.4

Steps to Reproduce:

1. Clone my repro at https://github.com/jeffb-sfdc/SourceUriBug. This is a boilerplate VS Code extension, with two commands that were added
2. Follow the steps listed in the README.md file of the project:

To reproduce the bug:

1. Run VS Code with this extension
2. Open a project
3. In the explorer, right-click on a file and select Rename.
4. Rename the file's name. Only change the case of some of the characters, don't add or remove characters. (eg. rename homepage.html to homePage.html)
5. In the explorer, right-click the same file and select Example Tree Node Command

Result:
When debugging, you should break into exampleCommand(). Observe the sourceUri that's passed in, and notice that the paths in sourceUri are to homePage.html, which is expected.

6. If not already opened, open the file that was renamed (eg homePage.html)
7. Right-click within the editor and select Example Editor Command

Result:
When debugging, you should break into exampleCommand(). Observe the sourceUri that's passed in, and notice that the paths in sourceUri are incorrect, and are the stale/original homepage.html.

There are two bugs here:

1. After a file has been renamed by a user, the VS Code APIs return the stale name
2. The sourceUri passed when invoked via the explorer is a different from the sourceUri that's passed when invoked via a contextual menu in a document.

This is a call driver for us and has already resulted in a few tickets opened against us. Our platform requires the name of the class to match the name of the file. This (the renaming of the file and then getting a stale sourceUri) fails in a number of ways for us.

One scenario that's happening is after a file has been renamed (let's say, from FOO.JS to Foo.js), and within the file
public class FOO is renamed to public class Foo
...a command within our extension is invoked and the file is uploaded to our platform.

When the command is invoked, we get a sourceUri with FOO.JS instead of Foo.js, and when we attempt to upload, we pass the contents of the file along with a name of FOO.JS. On the server, there's a mismatch since FOO.JS doesn't align up with public class Foo and the operation fails.

[lramos15]

Just to check if you do these in reverse order is the tree URI always correct and the document is always wrong or is it just the second action that is always stale?

[jrieken]

Observe the sourceUri that's passed in, and notice that the paths in sourceUri are incorrect, and are the stale/original homepage.html.

On file systems that are case-insensitive (e.g mac, windows) we continue to use the old resource, we call that the canonical uri because any casing variant points to the same, correct resource.

[jrieken]

I am closing this as designed because we don't change the URI of documents (which are bound to editors) is such cases.