Reset Session before launching debugger

[Hypernut]

I love the fact that after having run a script via the debugger, the variables and objects are still available in the console.
But launching the debugger again, does not reset the session as well, what can cause unintended side effects, due to stuff created in the session like background jobs, variables, other runspaces and so on.

This is such an big obvious problem for me that I do wonder why nobody seems to bother, which in turn makes me think: do I simply use it wrong? :)
But I am not aware of any way to remove, clear and close really everything than can be created, opened or assigned in a PoSh-Session, to avoid any potential problems, other than: killing the terminal manually and lauching a new session.

So I would like the option that every time the debugger is launched it either resets the session or creates a new one (an killing the old).

[corbob]

The setting powershell.debugging.createTemporaryIntegratedConsole isn't exactly what you're asking for, but it does create a temporary console that lasts just for the run of the debugger.

That being said, I think it would be helpful to have an option that spins up a new console that stays around until the next debugging session (I also have no idea how that would work).

[Hypernut]

No, unfortunately the temporary console does not allow interactive debugging and is therefore -at leat to me- useless.

[corbob]

I must be confused by what you mean by interactive debugging. In the stable extension I am able to use a temporary session and debug the script:

The session doesn't stay active, but the terminal window does until you start another debug.

[corbob]

Ignore what I posted there. I just saw #1263 while submitting a bug where the preview is failing (looks like log permissions). What I didn't try was actually doing stuff in the terminal while at a break point. It appears you can only do a single command and then nothing else in the terminal.

[TylerLeonhardt]

This is fixed in the next release that'll happen this week.

[Hypernut]

If you mean v2020.1.0 by "next release" then it is not.

[TylerLeonhardt]

I was referring to @corbob's issue about the log file permissions.

[rjmholt]

So I would like the option that every time the debugger is launched it either resets the session or creates a new one (an killing the old).

So this is very much the scenario that the temporary console is intended to address.

No, unfortunately the temporary console does not allow interactive debugging

Could you elaborate on what you mean by interactive debugging here?

Is the debugger not launching for you when you run a script in a temporary console?

But I am not aware of any way to remove, clear and close really everything than can be created, opened or assigned in a PoSh-Session

Unfortunately this is not a trivial thing to do. It's probably possible (I believe it's how the AzF PowerShell worker does things), but not at all foolproof.

More importantly, it's contrary to what other many other users expect, which is for a script that they run in the debugger to permanently alter state. More than this, there's other state that's changed in PowerShell by the extension (such as what breakpoints are set), and resetting things would wash a lot of that away.

So ideally I think we can work out what part of the temporary debugging experience isn't working for you and try to address that. Given that a process is the operating system's unit of context (so that having a new process amounts to a fresh context), it feels like pursuing that is the right solution to your request.

[Hypernut]

Thanks for taking the time to address this.
By interactive debugging I mean, whenI hit a breakpoint, I am able to use the console to query variables and do stuff in the console with all the variables assigned up to this point in the script.
There is a bug in the temp console and because of this you can type in one command and then nothing else.
Also the temp console does not allow to query variables and stuff AFTER the script ran.

More importantly, it's contrary to what other many other users expect,

PowerGUI, the editor I was "growing up" with as a Posh-developer, had this built in.
But yes, was wondering about that. But for me it is an obvious thing. For example if you're debugging scripts with jobs, runspaces, you don't want the old ones hanging around if you make a change and restart the whole thing. Or even just variables. I mean does everybody besides me either clean up all the variables after running a script or assigning them a zero value at the beginning? If not you start the script again and have odd effects if you e.g. relying on a variable only to exist in some cases.
Maybe its bad programming on my part.

But I don't get the "difficult" part, because what I currently do as a workaround is: just killing the console with the "trash"-button and restarting it again and then start the debugger. That works fine, but takes a few clicks and a two seconds wait after restarting the console before the debugger is available again. So its just an annoying thing if you do that 100 times a day.
And that should not be too hard to automate, or is it?

[rjmholt]

just killing the console with the "trash"-button and restarting it again and then start the debugger. That works fine, but takes a few clicks and a two seconds wait after restarting the console before the debugger is available again. So its just an annoying thing if you do that 100 times a day.
And that should not be too hard to automate, or is it?

Well that kills the whole PowerShell process driving the extension, which is pretty state driven.

Automating that is essentially what the temporary console is supposed to be. It starts another PowerShell process with a lighter-weight server in it (just the debug service, rather than the language service as well).

So my thinking is that we should investigate these bits:

There is a bug in the temp console and because of this you can type in one command and then nothing else

Also the temp console does not allow to query variables and stuff AFTER the script ran

[Hypernut]

So my thinking is that we should investigate these bits:

There is a bug in the temp console and because of this you can type in one command and then nothing else

Please do. :-) There is bug open for that for nearly two years. :) #1263 (comment)
That is why I thought this way might be easier...

Also the temp console does not allow to query variables and stuff AFTER the script ran

Maybe ot is supposed to that and its due to the same bug it is not, I dunno.

[Hypernut]

@rjmholt So, that was it? :)

[rjmholt]

So, that was it? :)

I may be misunderstanding what you're asking, but if you're asking about progress on this, we're currently concentrating on these issues. We tend to prioritise issues based on a combination of severity and demand, and those ones are taking all of our attention at the moment. Ideally when we've driven down that list we'll be able to look into the temporary console issues more. We're also always open to taking PRs and have taken many significant community contributions so far.

[gbakeman]

Hoping this could be considered more of an important issue, especially if you're not used to manually cleaning up a debug session before starting another. It's definitely caught me off guard several times when I'm wondering why I get two different results across debug sessions. 😅 In my mind, VSCode would just open a new pwsh session when you launch a debug, then leave it after for the user to close. Right now, my workflow involves running the debug, then deleting the open powershell session, which causes the extension to throw up several errors detecting that its session was closed, and accepting the prompt to launch a new session. Hopefully this isn't causing any other issues with the extension.

[corbob]

Right now, my workflow involves running the debug, then deleting the open powershell session, which causes the extension to throw up several errors detecting that its session was closed, and accepting the prompt to launch a new session.

@gbakeman you might be pleased to hear you can open the Command Pallette (Ctrl+Shift+P on Windows) and run PowerShell: Restart Session to have it restart the session without all those errors popping up.

[gbakeman]

That does help a lot, thank you! 😊

[andyleejordan]

Does the setting powershell.debugging.createTemporaryIntegratedConsole help at all? It's persistent as long as you're debugging, so you can use the console and inspect in it, but you'll get a new one each time you debug (which should be the "reset" semantics being looked for here).

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[gbakeman]

I think the workarounds you @andyleejordan and @corbob gave are actually working well in their own ways. I kind of like yours more since it works as more of a set-and-forget kind of thing. Although I understand how people may want their session to remain the same through debugging sessions, so I may forget and end up here again to change it back. Thank you, both! ☺️

Edit: I also wanted to add that the terminal session remains open despite an exit call at the end of the script. I thought I had to add a work-around before to keep the terminal open (maybe that was from running it manually in Windows Terminal), but either way, it's great to be able to manually bin the session once I'm done with it.

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[JustinGrote]

@gbakeman it stays open so you can review output if needed, we could maybe add a "close on exit" preference but it'd probably be on the backlog for a while unless someone takes it upon themselves to PR it.

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[gbakeman]

Sorry if I was unclear, but I actually do prefer it staying open (had to have a workaround to stop it) but thank you regardless!

[github-actions]

This issue has been labeled as resolved, please verify the provided fix (or other reason).

[github-actions]

This issue has been labeled as needing fix verification and has not had any activity a week. It has been closed for housekeeping purposes.