Change:
this.#proxy.$setEntry(this._entryId, id, name, this._text, tooltip, this._command?.internal, color, this._backgroundColor, this._alignment === ExtHostStatusBarAlignment.Left, this._priority, this._accessibilityInformation); <ins> // clean-up state commands _after_ updating the UI this._staleCommandRegistrations.clear(); </ins> }, 0); }

Discussion:
Type: <bBug</bThe users of our extension do see this error pop-up <img width="565" alt="Capture d’écran 2022-11-02 à 15 32 11" src="https://user-"It's also present in the console <img width="539" alt="Capture d’écran 2022-11-02 à 14 41 09" src="https://user-"It happens at random, but can 100% be reproduced by spamming a status bar button that runs a command. It seems like there is a sleeping bug in the vscode codebase, and our extension is triggering it for some reason. Note that there isn't an expansion triangle on the pop-up, and that the pop-up does not come from the extension. The status bar button runs a command that focuses an item in a TreeView. The bug seems to happen only when the tree view is being updated: to reproduce you need to spam the button while the treeview is being refreshed. I'm unsure of the correlation but it's a reliable way to reproduce. <details<summarySteps to reproduce</summaryHere are some steps to reproduce, for what it's worth. They're a bit annoying since it requires an account with CircleCI, but all it does is provide a status bar button that we can click. in and select a project -run a workflow the status bar button ("CircleCI: Running") while the tree view is being updated with the workflow you just re-run observe the error pop-up. Otherwise, try again from step 3 </detailsIf the root cause cannot be identified, could you please provide us with a way for users to not have this error pop-up? Just a console log would be enough. Relates to The error comes from here in the vscode codebase: I cannot attempt to reproduce on insiders because of another pending issue.

VS Code version: Code 1.72.2 (Universal) (, 2022-10-12T22:16:30.254Z) OS version: Darwin arm64 21.4.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ Bookmarks13.3.1 circleci1.0.1 vscode-eslint2.2.6 gitlens12.2.2 go0.35.2 remote-ssh0.90.1 remote-ssh-edit0.84.0 vim1.24.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
These errors occur when disposing a extension host side command too early, when they are still used in the renderer
Do we know which command is disposed here that triggers the error? Can we print the ID of the command?
Unfortunately not - it's one command for all (complex) EH side command
wait... maybe I can add some debug info here
I don't know how useful this information will be, but I've started seeing this error in TypeScript workspaces after upgrading to 1.73. It seems to mostly occur after applying a suggestion from the "lightbulb" menu, but I haven't been able to work out how to reproduce it reliably yet.
makes the error message better - but the programming mistake is the same. We dispose a "cached" EH command even though it is still used (referenced) in the UI
This is what it looks like after your commit ! is the command that is executed when clicking on the status bar item is not declared in the I don't know about the suffix
what does "spam the status bar button" mean?
By spamming I mean clicking on it multiple times in a row as fast as possible until the problem reproduces It is possible that the status bar item command is updated every time we click on it
that is possible if running the command updates the status bar entry...
Some users of our extension do randomly see the error message while using the extension normally. Spamming the status bar item that updates its own command is one way to reliably reproduce the issue, but this is just a way to reproduce and is not the core of this bug report.

Since the message comes from VS Code itself, there aren't many options available to us so that our users do not to see the message again. It is not known whether some status bar item clicks are ignored (do not execute the desired command).
Why do the commands need the suffix and change all the time?
If the question is for me, I don't know. Our extension is not suffixing the commands. Regarding the label, do you need more information from me?
After a 1on1 with Jo, we found that this command disposal might run too early before the UI was updated: Because the update runs with a : However I think there is more to it because updating the UI needs to communicate with the renderer process which is async by nature. So I think a better way of disposing the command is when we truly know that it is not used anymore from the renderer. is it possible that the command that you register with the status bar itself modifies the status bar entry immediately, i.e. sets the command again to the entry?
It is possible. At the very least I know we update the status bar frequently Thanks for investigating
we will need a simple hello world snippet to reproduce. I tried this but cannot trigger this, at least on macOS: Can you provide a small snippet that reproduces? My snippet above sets the command each time you click.
I can't reproduce using the snippet above either. But with my extension it's easily reproducible. I'm on macOS too. Do you really need a small snippet, or would a VSIX with a kind of self-reproducing issue do the job? Meanwhile, the issue can still be reproduced by repeatedly clicking on the status bar item immediatly after re-running or cancelling a workflow with the https://user-
A standalone snippet would speed this up if you are interested in a fast turnaround. Also I am on macOS, not sure that makes an impact, could be harder to reproduce on macOS.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Creating a standalone snippet will take some time. My colleagues or I will do it at some point. You can park this ticket for now. Thanks for investigating