Explore how to simplify the code for managing connections to local and remote Jupyter Servers

[DonJayamanne]

Tasks

Beta Give feedback

1. Python API is used indirectly in Web Extension #13610
   debt +1
   
2. Rename IJupyterSessionManager #13578
   debt +1
   
3. Export Notebook for Web: call JupyterLab#ContentManager directly to simplify JupyterKernelSession #13577
   debt on-testplan +2
   
4. Move password manager into UserJupyterServer plugin #13631
   debt on-testplan +2
   
5. Remove usage of URI and ServerId as identifier for Jupyter Servers #13632
   4 of 4
   +0
   
6. Invalid password not cleared until we start VS Code #13633
   debt +1
   
7. Unable to connect to Kernel of updated remote Jupyter Server without restarting VSCode #13488
   author-verification-requested bug info-needed notebook-remote verified +5
   
8. [BUG] Infinity token-authenticated request when connected to remote jupyter server #13345
   bug info-needed notebook-remote +3
   
9. Jupyter cannot connect to a remote server using a custom ServerPicker #13112
   bug info-needed notebook-remote +3
   
10. Connecting to remote jupyter server issues #13015
    bug notebook-kernel-remote notebook-remote verified +4
    
11. Failed to connect jupyterhub. #8134
    bug info-needed notebook-remote remote-connection-failure verified +5
    
12. Unify remote kernel finder with ServerUriStorage #11645
    debt notebook-kernel-remote notebook-remote on-testplan +4
    
13. Deprecate/remove jupyter.selectjupyteruri as an extensibility point for 3rd party extensions #13300
    debt notebook-kernel-remote notebook-remote +3
    
14. We never clear old cache if a Remote Uri is deleted, this cache key lives forever #13634
    debt +1
    
15. If we have a token for a Jupyter Server, then why check and prompt for passwords #13635
    debt +1
    
16. Cannot connect to existing Jupyter Server: "... Server with this URL already exists" #13637
    debt notebook-kernel-remote +2
    
17. Stop waiting for all Remote Providers to load and activate when getting a list of Remote Kernel Providedrs #13808
    debt notebook-kernel-remote perf +3
    

[DonJayamanne]

Problems

Ambiguous Uri, Url, ServerId #13540

• The term Uri is used in a number of places to point to the address of the Jupyter Server as well as an identifyer for a Jupyter Server.
  • Without inspecting the Uri we have no idea what it is, hence we have if conditions in a number of places
  • Unfortunately there are places where this if condition isn't used and has caused bugs (password storage and connection)
  • Error messages and the like assume the Url is the Jupyter Server Uri, but its not.
  • Basically its just too complex
• The Uri is constructed from the Jupyter Provider Id and Handle, however without the extensionId it is not unique.
  • Its possible to have two extensions with the same provider id, and this can cause issues when we try to connect to them.
• The Uri is constructed from the Jupyter Provider Id and Handle
  • Hence Uri is kind of always unique (provided we include the extension id into the mix)
  • Thus we do not need computeServerId
  • We have serverId used as identifiers in a number of places, along with this Uri as well
  • We have two types of identifiers

Suggested Solutions:

• Remove serverId
• Replace serverId with the Uri
• Replace Uri with an object, today its called idAndHandle, its basically a Jupyter Server Identifier (lets call this JupyterServerProviderHandle and will include extensionId as a new property

Invalid password not cleared until we start VS Code

Root cause is the same as the previous problem. Uri !== Uri

Server already exists

When attempting to add a new Server sometimes we end up with the error indicating this already exists.
The problem is basically related to the previous issue as well as tech debt.
Root cause is not yet known, but the code is a little too complex and we have too much state (instead of getting the latest state from memento/auth storage).
It seems the in-memory state is stale and users run into this issue.

Suggestions:

• Remove the cache of _servers or only leave that when adding a new server and then remove that.
  I.e. where possible remove the caches.

No proper connection validation stage when starting a remote kernel

When connecting to a server (or starting a kernel), this is what we do:

• Create the connection IJupyterConnection
• Next, start the session with the SessionManager using the IJupyterConnection
  It is at this point that the connection is validated.

Problem:

• If the password is invalid, we validate that when starting the session, not when creating the connection
• If some other information is invalid then the same as above

Question:

• Should we have a separate step when we verify/validate the connection
  • Today we have a separate validation step only when selecting a kernel from a provider (e.g. when adding a Remote Jupyter Uri from the existing kernel Picker)

Suggested Solutions:

• Have a separate step to validate the connection
  The benefits are that we can easily update the code to incorporate management of the connection, updating the password, etc.
  Else adding all of this into the session creation code/layer seems messy.

Debt: Not waiting for async Session disposal to complete

In JupyterConnection.ts when we dispose the session, we do not wait for it to finish after we've validated the connection information.
Method validateRemoteUri, code sessionManager.dispose().catch(noop);

• We never clear old cache if a Remote Uri is deleted, this cache key lives forever ${ContributedKernelFinderKind.Remote}-${serverHandleId},

• If we have a token for a Jupyter Server, then why check and prompt for passwords,
  Both steps are totally unnecessary (more ui and more points of failure).

• Rename IJupyterSessionManager #13578

• Export Notebook for Web: call JupyterLab#ContentManager directly to simplify JupyterKernelSession #13577

• Move the code that creates the ServerConnection.ISettings object from our IJupyterConnection into the Connection layer.
  This is related to how Jupyter Lab connects to the remote servers, has nothing to do with sessions.
  Hence this method should be removed from JupyterSessionManager into the JupyterConnection class.
  E.g. we could add a method JupyterConnection.toJupyterConnectionSessions(IJupyterConnection)

[amunger]

removing from verification queue