Fix changing interactive window kernel when the active interpreter does not have ipykernel installed #7469
Conversation
This reverts commit ab5e5bf.
| @@ -77,7 +77,7 @@ export class KernelProvider implements IKernelProvider { | |||
| this.pendingDisposables.clear(); | |||
| await Promise.all(items); | |||
| } | |||
| public getOrCreate(notebook: NotebookDocument, options: KernelOptions): IKernel | undefined { | |||
| public getOrCreate(notebook: NotebookDocument, options: KernelOptions): IKernel { | |||
There was a problem hiding this comment.
Eew, can't remember why I ever returned undefined, so wrong
Codecov Report
@@ Coverage Diff @@
## main #7469 +/- ##
=====================================
- Coverage 64% 64% -1%
=====================================
Files 361 361
Lines 22511 22505 -6
Branches 3424 3422 -2
=====================================
- Hits 14569 14536 -33
- Misses 6727 6745 +18
- Partials 1215 1224 +9
|
|
Ended up reverting the change I was attempting to not cache the kernel in the IW. Debugged it locally and it appears to cause execution to slow down significantly for the #%% cell codepath (input box codepath is fine). |
… start failures don't get cached after switching controllers
(We are no longer autostarting a backup kernel, so the original reason for making the dialog non-modal is moot)
… selected for this IW, and dispose all selection change listeners in IW.dispose
| const selection = this.isCodeSpace | ||
| ? installPrompt | ||
| : await Promise.race([ | ||
| this.appShell.showErrorMessage(message, { modal }, ...options), | ||
| this.appShell.showErrorMessage(message, { modal: true }, ...options), |
There was a problem hiding this comment.
Making this modal for now since changing controllers while we're attempting to connect to a kernel does not cancel that connection (kernelProvider still returns the existing kernel promise)
| public get readyPromise(): Promise<NotebookEditor> { | ||
| return this._editorReadyPromise; | ||
| public get readyPromise(): Promise<void> { | ||
| return Promise.all([this._editorReadyPromise, this._kernelReadyPromise]).then(noop, noop); |
There was a problem hiding this comment.
Previously the kernel promise was part of the editor ready promise, so if the kernel failed to start e.g. due to ipykernel not being installed, subsequent executions would fail while awaiting on the editor ready (if the kernel promise successfully resolved, there wasn't an issue). PR splits out the kernel promise
Fix #7288