Notebooks - Variables disappear for a moment when run by line enabled

[claudiaregio]

Environment data

• VS Code version: 1.61.0-insider
• Jupyter Extension version (available under the Extensions sidebar): v2021.9.1001277548

Steps to reproduce:

1. Open Notebook
2. Run all cells
3. Open variable explorer when done
4. Start run by line on a cell

Actual behavior

Variables go away and it flashes 'No Variables Defined' for a moment

Expected behavior

For variables not to disappear

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

[DonJayamanne]

Is this a golden scenario
The workflow here is similar to #7740

• User runs some cells & then uses RBL
  Based on the discussions this isn't a normal usecase for RBL, however the argument here is that this is a common use case hence a golden scenarion.

I think we can push this off till later, feels this is more like polishing of RBL.

[DonJayamanne]

Unable to repro, @claudiaregio Please could you try this again and confirm you are able to repro this.

[DonJayamanne]

I think i can see how we'd end up in a situation where variables aren't displayed:
Here's the flow of events:

• View variables (request sent to kernel)
• Start debugging
• Display debug console & variables view is no longer visible
• Next, display variables view (i don't know who's switching from debug console to varaibles view, possible we are or possible vscode core is)
• Next variables view is visible & we're trying to get variables
  • At this point we check if we have a debug session, assume debugger has not yet started completely
  • We sent a request to kernel
  • But at the same time debugger has started & stopped at the first line
  • Now, kernel is stuck (debugger has control of the process thread)

I think we need a better way to check if a debugger is attached, instad of checking if somethign is attached, we need to look at the pending state.
No point sending requests for variables when user is in the middle of starting a debugger session.
If user is in the middle of starting a debugger, session then we should either:

• Block the debugger & fetch variables
• Or start debugger & then fetch variables

[claudiaregio]

@DonJayamanne Yes I can still repro consistently

[DonJayamanne]

@claudiaregio Thanks, I've added comments above, this will require a bit more work.

• We need to create a new variable that will tell us whether a debugger is starting or not & if starting, then fetch variables from debugger
• Also, we should cache the variables for a given notebook,
  • This way, when we toggle between variable viewer & some other UI, if the notebook is the same, we don't need to re-fetch the variables.
  • Right now the problem is when we attempt to re-fetch variables, its locked (as debugger has stopped) & kernel is now busy.

Had a chat with Rich, and he agrees, we might need a bit of clean up here (some work was left un-done and was supposed to be completed, guess we never go to them).

[greazer]

Perhaps related to #7970? Or at least the two may be readily fixable together.

[rchiodo]

The situation that Don describes is possible, but I don't think that's the cause of the problem Claudia is showing. We just always refresh whenever we stop on a breakpoint. Just like the C++ debugger. Should we special case the first line to skip such a refresh? Maybe? I'm taking this off of the fix now list and putting back in triage.

Right now this behavior is by design.

[greazer]

Thanks for the feedback! However, we don't have plans on fixing this at this time. :)