April 2020 release (version 1.45) completely breaks ability to connect to remote Jupyter server

[daniel347x]

Issue Type: Bug

Follow the same steps that work in the Mar 2020 and prior releases to connect to a remote Jupyter server.

• Confirm that a remote Jupyter notebook server is running, and locate its URL (including token) to access it from the Visual Studio Code system.

• In Visual Code, press Ctrl+Shift+P to bring up the commands window

• Type "Jupyter" and, from the choices, select the option that reads "Python: Specify local or remote Jupyter server for connections"

• Choose "Existing" in the dropdown that follows

• Paste the full URL of the remote Jupyter notebook server, including token, into the edit box that appears, and click Enter (twice) to save and exit the setting

• When prompted, reload Visual Code

• Open an existing local Jupyter notebook file (with extension .ipynb)

• Attempt to execute a cell, such as "2+2"

At this point, Visual Code will attempt to connect to the remote Jupyter server. Quickly, it will fail, reporting a 403 error.

I attempted the above numerous times, restarting my computer, modifying the jupyter_notebook_config.py file (which I have never had to do to connect), but nothing worked.

Then I realized that just today, I had accepted the automatic update to the April 2020 build of Visual Code (version 1.45).

I downgraded to the Mar 2020 build (version 1.44) and the problem was not present - I was immediately able to connect to my remote Jupyter notebook server.

The problem clearly lies with the April 2020 build of Visual Code (version 1.45). This build has completely broken the ability to connect to a remote Jupyter notebook server.

Extension version: 2020.5.78807
VS Code version: Code 1.44.2 (ff915844119ce9485abfe8aa9076ec76b5300ddd, 2020-04-16T16:36:23.138Z)
OS version: Windows_NT x64 10.0.18363

System Info

Item	Value
CPUs	Intel(R) Xeon(R) Gold 6154 CPU @ 3.00GHz (36 x 3000)
GPU Status	2d_canvas: enabled flash_3d: enabled flash_stage3d: enabled flash_stage3d_baseline: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off protected_video_decode: unavailable_off rasterization: enabled skia_renderer: disabled_off_ok video_decode: enabled viz_display_compositor: enabled_on viz_hit_test_surface_layer: disabled_off_ok webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	223.65GB (184.65GB free)
Process Argv
Screen Reader	no
VM	36%

[DonJayamanne]

@pkgandhi @daniel347x
Thanks for reporting this issue and we're for regressing here.
Please note: I'm unable to replicate this at my end.

To better understand the nature of this regression, I'll need the following information:

• Version of Python (displayed on bottom left VS Code status bar)
• Output from Jupyter console
  • Select the command Python: Show Jupyter Output
• Output from console window
  • Select the command Developer: Toggle Developer Tools
  • Go into the console window
  • Save the console window output into a text file and upload here.
• Finally Screen shots of the error

[DonJayamanne]

@pkgandhi
Please could you provide the following information:

• OS
• Version of Python extension
• Version of VS Code

[DonJayamanne]

I downgraded to the Mar 2020 build (version 1.44) and the problem was not present - I was

@pkgandhi @daniel347x

• Please could you confirm the following fixes it:
  • Older version of VS Code 1.44
  • But latest version of Python extension 2020.5.78807

If this is the case, then it would narrow down the cause to an upstream issue in VS Code.

[daniel347x]

I cannot reproduce success with either the older version of VS Code (1.44) or an older (or current) version of the Python extension. All cases are now returning 403 errors for me, so it seems likely this is an issue with my Jupyter server setup.

I can access and run the Jupyter notebook via a web browser, so there is some issue with either VS Code or the Python extension, however.

But the issue is, apparently, not tied to the current version, so you can close this issue, and sorry for the false alarm.

Thanks.

[andybrnr]

Hi all,

I'm running into issues with the remote kernel access as well. We have a remote JupyterHub server on AWS that I can access fine through Atom with the Hydrogen plugin. I'd really like to move to VS Code, but remote kernel support has been the limiting factor. When I set the remote server URI in folder settings, it seems to ignore it in favor of the last local kernel I used in a different workspace.

Steps to reproduce:

• create .vscode dir with settings.json file in project repo with configuration of

{
  "python.dataScience.jupyterServerURI": "https://<<redacted url>>/user/<<redacted user>>/?token=<<my token string>>"
}

• reload window
• kernel selector reverts to a running local kernel, clicking the box with local kernel name displays the list of local kernels and not remote kernels, no error messages thrown

Haven't been able to get it to talk to the remote server while I have Atom + Hydrogen running next to it quite happily. Any thoughts appreciated, happy to grab any logs that would be helpful if you let me know what's needed.

[greazer]

@andybrnr, can you check to see if https://github.com/microsoft/vscode-python/issues/11002 looks to be identical to the issue you're seeing? If so it would be great if you could comment there, and let us close this particular issue as I believe you're running into something different than @daniel347x originally did.

[andybrnr]

@greazer I don't think microsoft/vscode-python#11002 is quite identical... I'm trying to connect to a standard jupyter notebook server running on a standalone EC2 instance we set up, not a SageMaker notebook (from reading microsoft/vscode-python#11002, sounds like AWS did some modification of the notebook server auth model for their hosted solution). I Iooked at the console logging in developer tools, see no evidence that it even tried to hit the remote server (no activity in the network traffic monitor). Completely willing to believe this is a case of PEBKAC, but if so, not sure what I'm doing wrong. I can create a new issue if that's preferable.

[greazer]

We need a repro to investigate this issue further.

[andybrnr]

Hmm, will see what I can do. Cloud infrastructure component makes things a little tricky to give a full repro with spinning up a JH server on AWS to run against. The lack of any network traffic in the developer console makes me think it's something more basic in how the local conda environments are being selected in preference to the the remote jupyter URI. Do you have a suggestion for attempting to construct a minimal repro? Andy

…

On Mon, Jun 1, 2020 at 1:58 PM Jim Griesmer ***@***.***> wrote: We need a repro to investigate this issue further. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/microsoft/vscode-python/issues/11804#issuecomment-637098214>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFLIZCLSO7EP6Y67BGC6HDRUQJAHANCNFSM4NAIH2IA> .