Change:
return; } <del> if (this._onDidChangeSecret.isPaused) { this._logService.trace(`[SecretStorageService] Skipping change event for secret: ${key} because it is paused`); return; } </del> const secretKey = key.slice(this._storagePrefix.length); this._logService.trace(`[SecretStorageService] Notifying change in value for secret: ${secretKey}`);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.80.0 () OS Version: macOS 12.5.1 (21G83) Steps to Reproduce: an extension listens for changes in the secrets store and calls when there is a change (for example), using . the secrets store, using Expected behaviour: The change listener should fire and the log message will be seen in both the current VS Code window, and any other VS Code windows which are open where the extension is running Actual behaviour: In VS Code 1.8.0 (and also Insiders and VS Code built from source from the latest ), the listener never fires in the window where the update was made. It does fire in other windows. In 1.79.2, the listener would fire in the instance where the update was made. It seems the behaviour changed in , specifically . It may be that this is a deliberate change, in which case it should be documented, but it seems somewhat surprising/a bit of a regression to me, as now you need to make sure you manually invoke any secret store change handlers in addition to using a listener. This broke some functionality in our extension which was working in 1.79.2, the workaround is just to call the change handler manually at the point of updating the secret store, but this means you have to remember to do this in multiple places potentially and breaks my expectations around how the listener would work.

Repro: This example extension provides a minimal repro of the bug: Running the extension and triggering the "Hello World" command will log in the regular VS Code build, but will not log anything in Insiders.
Thanks for calling this out. I originally did this because you already have the secret you're storing in the window you're storing it in... but this is changed behavior so I'll change it back. We'll also include it in the 1.80 recovery which will be next week.
Cool, thank you! Yeah, in our case we are doing something in response to the secret changing, so with the current behaviour we have to have both a change listener (for other windows), and a manual call to the listener (for the active window).
Hi! We're having the same problem in our extension . could you share what you did to manually call the listener?
Closing this since the PR is merged and it'll be in 1.80.1
Hey - I just mean something like:
Verification in Stable candidate: download the zip, unzip it, and install the VSIX: open two VS Code windows Run the command You should see a notification in each window saying that a secret changed in 1.80.0, you would only see it in the window that you didn't run the command in.