Change:
const extensionScannerInput = new ExtensionScannerInput(c.resource, input.mtime, input.applicationExtensionslocation, input.applicationExtensionslocationMtime, input.profile, input.type, input.excludeObsolete, input.validate, input.productVersion, input.productDate, input.productCommit, input.devMode, input.language, input.translations); return this.scanExtension(extensionScannerInput); })); <del> return coalesce(extensions); </del> <ins> return coalesce(extensions) // Sort: Make sure extensions are in the same order always. Helps cache invalidation even if the order changes. .sort((a, b) => a.location.path < b.location.path ? -1 : 1); </ins> } private async scanExtensionsFromProfile(input: ExtensionScannerInput): Promise<IRelaxedScannedExtension[]> {

Discussion:
Issue Type: <bBug</bCode with the CLI cached extension scanner prompts to reload window, even though extensions have not been changed The only unusual thing about my setup is that my extensions in are symlinks, but this issue has never occurred in the months past. Logs don't really show much, the most I see before the issue is reproduced is that the cached extension scanner scanned all system and all my user extensions. VS Code version: Code 1.67.2 (, 2022-05-17T18:20:04.972Z) OS version: Darwin arm64 21.5.0 Restricted Mode: No <details<summaryExtensions (5)</summaryExtensionVersion ------ EditorConfig0.16.4 nix-ide0.1.19 rust-analyzer0.3.1059 just2.0.0 even-better-toml0.14.2 (1 theme extensions excluded) </details<!-- generated by issue reporter --
This could be the root cause - we cache all of extensions under this folder and invalidate the cache only when mtime of changes. And in your case, there is more possibility that changes in of sym linked extensions can cause this. When you see a prompt mentioning extensions are modified on disk and reload is required, can you please check if the contents of sym linked extensions has been changed?
The contents have not changed -- checked by hashing them all prior to open Code and then again after the prompt appears.
Can you please share/compare the content of the cache file before and after opening the Code? You can find the cache file at the following location.
The issue is that one of the object's position in the map is being moved -- but the contents of the object unchanged ().
The most obvious fix for this issue would be sorting the extensions array in by some key, extension ID maybe, just to ensure stability. Would this be a suitable fix, or do you think there's a more proper way to go about it? (I'd be happy to implement + PR this, or any other solution you suggest.) I do wonder why this is even happening though -- I'd assume that it's just a race condition like issue where one scanner Promise is completing quicker than the other? Definitely weird how consistently it happens, though...
Hmm, its really strange. I am wondering why the order is being changed.

We just read the extensions (folders) as is from the disk and I would expect it shall return the folders in the same order. I would not want to fix the sorting until we understand the root cause. Can you please give me all details when this is happening for you? You see it all the times? Do you see it only when one window is open?
More often than not, yes. I've had one window open, opened another with the CLI, and then have it occur in the new window.
Any insights here? It seems the user is seeing reload prompt from cached extensions scanner and when comparing old cached file with new cached file, only change is that one extension is at a different location (order has changed) - One unusual thing about user set up extensions in are symlinks. Have you seen something like this before?
I think I might have seen this behavior before, because I remember adding sorting by folder name at one point in the extension scanner. is the sort the code was doing before. Maybe that got lost in the refactoring from a few months back. is where the sort was first , when I first did extension caching. I don't remember why I it, maybe I observed weird fs behavior.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Looks like this is working now, thanks Though I wonder why this even cropped up in the first place, or why it only started happening when it did (and not when the scanner was implemented). As someone who has worked with the scanner a lot, if you have any ideas, I'd be curious to hear them.
/verified