Change:
<!-- 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/No <!-- 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. --We might want to veto extension host auto restart when users are using a notebook kernel. Auto restarting will lead to data loss.
Are you looking for some API support here? Do you have an idea how to veto here?
it's the most accurate if it can be controlled by extensions (since only kernel extensions know if the kernel is stateful or not), but I think maybe we can start having an veto hook/api internally in renderer process, and the notebook component can veto whenever there is a notebook open and kernel selected. How does this sound to you?
We already have such an event in the workbench for the components to listen to and react
would you ever consider having an extension api, with which extensions can declare if they have intermediate state that can't be restored if EH restarts? Vetoing from the core can be a good start, but in practice only kernel extensions know if it should veto the restart. For example, GitHub Issue Notebook's kernel is stateless so it doesn't need to block the start. Jupyter should block if users are using a local kernel, but it should not if users are using remote kernels (as it knows how to auto reconnect). Asking for a more granular control since if we veto if there is a kernel selected, it might mean a good amount of data science users will never get "auto restart" since their main editor is notebook.
Actually we are trying to avoid that. But if it is needed, we can definitely work on it. It seems to be a problem not just during auto restart of extensions, but also when user restart extensions manually which can happen on profile switch / workspace trust / updating extensions. Seems to make sense to me.
Lets start with a veto when there is an open notebook. Should I go ahead and adopt the existing API in notebook land?
I adopted notebooks for auto restarting of extension host - Please take a look. This disallow auto restarting of extension host when there is an open notebook editor. I am planning to add similar fix for custom/webview editors.
Closing this and will open separate issue for custom editors
To verify: the setting a Notebook open extensions view and uninstall an extension that requires restarting extensions (You should see Restart Extensions button on uninstalling an extension) the focus to any other window and come back to the existing window sure the extension host is not restarted. the opened notebook and do Step 4. sure the extension host is restarted. Can you please verify this.
Step 5 fails. I'm uninstalling the Pull Requests extension for Step 3, and have a .ipynb notebook open for Step 2.

Discussion:
}); this._register(extensionService.onWillStop(e => { <del> if (!this.isDirty()) { </del> <ins> if (!e.auto && !this.isDirty()) { </ins> return; }