Vscode-jupyter: Jupyter bugs: Out of sync source code

[sotheanith]

Bug: Notebook Editor, Interactive Window, Editor cells

Steps to cause the bug to occur

1. Run long execution code like Keras neural networking training
2. Editing cells as code being executed while enabling autosaves
3. Sometimes code blocks show on vscode notebook is different than code blocks store on disk.
4. Have to close and reopen the file to see actual editing that occurs

Description

I encounter a problem with Jupyter notebook where source code on display in vscode is different that source code on disk(I assume this is the code executed by the kernel). I need to reopen the ipynb file to see the updated code. The problem usually occurs when cells are being executed and I make some editing to the code. For example, if I comment out multiple lines of code, it looks correct in vscode but it will throw a syntax error when I execute the cell. Upon reopening the ipynb file, the "#" is being inserted in the middle of a line instead of at the beginning like what vscode shown previously. Enable "Auto Save" causes the bug to occur more often. I started to have this problem two patches ago.

Actual behavior

VSCode Notebook before edit:

fc_model.add(layers.Dense(2500, activation="relu"))
fc_model.add(layers.Dense(2000, activation="relu"))
fc_model.add(layers.Dense(1500, activation="relu"))
fc_model.add(layers.Dense(1000, activation="relu"))
fc_model.add(layers.Dense(500, activation="relu"))

VSCode Notebook after edit:

# fc_model.add(layers.Dense(2500, activation="relu"))
# fc_model.add(layers.Dense(2000, activation="relu"))
# fc_model.add(layers.Dense(1500, activation="relu"))
# fc_model.add(layers.Dense(1000, activation="relu"))
# fc_model.add(layers.Dense(500, activation="relu"))

Code stored on disk after edit:

fc_model.add(lay#ers.Dense(2500, activation="relu"))
fc_model.add(layers.Dense(2000#, activation="relu"))
fc_model.add(layer#s.Dense(1500, activation="relu"))
fc_model.a#dd(layers.Dense(1000, activation="relu"))
fc_model.add(laye#rs.Dense(500, activation="relu"))

Expected behavior

VSCode Notebook before edit:

fc_model.add(layers.Dense(2500, activation="relu"))
fc_model.add(layers.Dense(2000, activation="relu"))
fc_model.add(layers.Dense(1500, activation="relu"))
fc_model.add(layers.Dense(1000, activation="relu"))
fc_model.add(layers.Dense(500, activation="relu"))

VSCode Notebook after edit:

# fc_model.add(layers.Dense(2500, activation="relu"))
# fc_model.add(layers.Dense(2000, activation="relu"))
# fc_model.add(layers.Dense(1500, activation="relu"))
# fc_model.add(layers.Dense(1000, activation="relu"))
# fc_model.add(layers.Dense(500, activation="relu"))

Code stored on disk after edit:

# fc_model.add(layers.Dense(2500, activation="relu"))
# fc_model.add(layers.Dense(2000, activation="relu"))
# fc_model.add(layers.Dense(1500, activation="relu"))
# fc_model.add(layers.Dense(1000, activation="relu"))
# fc_model.add(layers.Dense(500, activation="relu"))

Your Jupyter and/or Python environment

Please provide as much info as you readily know

• Jupyter server running: Local
• Extension version: 2020.3.69010
• VS Code version: 1.43.2
• Setting python.jediEnabled: true
• Python and/or Anaconda version: 3.6 and 4.8.2
• OS: Windows
• Virtual environment: conda

[rchiodo]

Thanks for the bug. This sounds like the edit commands are not propagating to the correct position in the notebook model.

Does this only happen when executing code? Or can you get it to happen just by editing?

[sotheanith]

Thanks for the bug. This sounds like the edit commands are not propagating to the correct position in the notebook model.

Does this only happen when executing code? Or can you get it to happen just by editing?

Hmm now that I think about it, yes this bug did occur when I do normal editing without any code being executed. However, it was only one time and it occurred after drawing big pyplot graphs.

[daragallagher]

It's difficult to reproduce but I've also observed something very similar to this after the last update. After working for a while, a strange syntax error will appear when executing a cell - the error message will refer to source that doesn't actually exist in the cell. If I save and restart, the cell will now show garbled text and the error message previously makes sense. I'm not explaining this very well but I'll try to add more detail the next time it happens. It's as if there's a synchronisation issue between text showing in the vscode cell and that actually stored in the notebook.

[rchiodo]

It's as if there's a synchronisation issue between text showing in the vscode cell and that actually stored in the notebook.

Yes that's what the bug is showing. We thought we had addressed all of these issues, but it seems there's still something going wrong.

[sotheanith]

I try the older version of python extension (2020.1.58038) and it doesn't have this bug.

[rchiodo]

Yes the model updating was different then. It was actually at a different level this problem would manifest itself.

[greazer]

Make sure the model update has been changed in the shipped version.

[DonJayamanne]

@sotheanith @RMeli @daragallagher @davidefiocco

Please could you try out insiders version of the extension. We believe this has been fixed, if not we'd like a confirmation so we can start working on this asap.

Instructions can be found here https://github.com/microsoft/vscode-python/blob/master/CONTRIBUTING.md#development-build (or just download the VSIX here)

[RMeli]

I'll try the insider version of the extension. I managed to reproduce this issue consistently: it happens every time I modify and save the notebook when a cell is executing; the code displayed and the code actually executed becomes different.

[RMeli]

After a few more test I don't get the error every time, but it happens often with the current version. I didn't menage to get the same errors with the insider version.

[rchiodo]

@DonJayamanne do you think this is fixed with https://github.com/microsoft/vscode-python/pull/10981? Sounds like it could be.

[rchiodo]

Closing assuming the fix for microsoft/vscode-python#10981 fixed this. Should be fixed in next release.