Local debugging in VS Code fails after app restart

[AnatoliB]

Repro steps:

1. Start a PowerShell Function app in VS Code by F5.
2. Wait for the app to start. Invoke a function or do not invoke any function - does not seem to matter.
3. Stop the app: hit the Disconnect button or push Ctrl-C in the terminal.
4. Start the app again by F5. About 2-5 seconds after the app start, it stops and the following message appears in the terminal window: Debug-Runspace: You cannot debug the default host Runspace using this cmdlet. To debug the default Runspace use the normal debugging commands from the host.

Further attempts to start the app fail with the same error, until VS Code is restarted.

[sebastianzolg]

Same here!

[JustinGrote]

This is happening to me @AnatoliB after upgrading to Core Tools 3.0.2881 Runtime 3.0.14287.0 Powershell Worker 3.0.293 using the Attach to Powershell Functions in VSCode

Also nothing works at the debug prompt in the integrated console (7.0.3), every command just hangs until I step but the command never evaluates. Watch variables still work though

[sebastianzolg]

@EricJizbaMSFT Could you please help and confirm? You seemed very active recently in regards to debugging issues in VSCode (thanks for that!).
—Sebastian

[ejizba]

Tried it out and I can repro on the latest func cli, but not on v3.0.2798. We changed (cc @pragnagopa) the message indicating when VS Code could attach the debugger to a debug-specific message ("Worker process started and initialized") that was supposed to be more reliable than the old/arbitrary message we were using ("Host lock lease acquired by instance ID"). I would guess this is a timing problem and for some reason the new message is printed too early for us to attach, but I have no idea how this PowerShell stuff works under the covers or what could be happening during the time between messages

Here are two workarounds in the meantime:

1. Downgrade to v3.0.2798
2. Modify your .vscode/tasks.json to use the old message:

   {
     "version": "2.0.0",
     "tasks": [
       {
         "type": "func",
         "command": "host start",
         "problemMatcher": {
           "base": "$func-watch",
           "background": {
             "activeOnStart": true,
             "beginsPattern": "^.*(Job host stopped|signaling restart).*$",
             "endsPattern": "^.*Host lock lease acquired by instance ID.*$"
           }
         },
         "isBackground": true
       }
     ]
   }

[JustinGrote]

@EricJizbaMSFT
I notice that Worker Process message doesn't show sometimes with Func Start since they changed the logging infrastructure in the newer version (and subsequently removed the functions logo which is another flamewar entirely). Maybe this is a regression from that?

[pragnagopa]

I will investigate and update the issue when I have more info. Thanks!

[AnatoliB]

These are great ideas. Please note though that debugging works fine once after VS Code start. After that, it is broken until VS Code restart.

[JustinGrote]

@AnatoliB in my case it fails every time, I think some others had the same.

[pragnagopa]

I can repro the issue.

@EricJizbaMSFT - I verified core tools output with latest version. It does print new log message : Worker process started and initialized - When this message is printed - worker process is started and initialized with indexed functions.

New Core tools version also added flag --verbose - this will give the same output as earlier versions. I tried adding the verbose flag - issue still reproes - I do not think this issue is related to logging changes.

[ejizba]

I agree it's not related to the verbosity changes. I think it has to do with the timing of when "Worker process started and initialized" is logged and when "Host lock lease acquired by instance ID." is logged. I was hoping someone familiar with the PowerShell worker could help identify what is happening between when those two messages are logged

[AnatoliB]

At this point, I don't know how the worker could influence this behavior. The "Worker process started and initialized" and "Host lock lease acquired by instance ID." messages are emitted by the host, not the worker.

Also, please note that we might be dealing with two potentially separate issues here:

1. The behavior I described at the beginning: the first attempt to debug works, the next attempt fails. VS Code is not frozen in general. I can repro this reliably.
2. VS Code freezes on the first attempt to debug. I've been unable to reproduce this myself.

[JustinGrote]

2. VS Code freezes on the first attempt to debug. I've been unable to reproduce this myself.

This might be local to me, I've been noticing console freezes in debugging in a lot of powershell places outside of functions they didn't normally happen before, I need to drop down to earlier powershell extension releases to verify.

[JustinGrote]

Just updating that this is still an issue and leads to an extremely poor debugging experience. Here's a twitter complaint:
https://twitter.com/Ehuggz1/status/1398276053827821570

[ehuggz]

@JustinGrote In the middle of a long debugging session, I suddenly started getting an error on Host lock lease. I did two things to clear up the error: 1) Create new Function App from VS Code and migrate code to new app. 2) Remove ALL Vscode extensions except those needed for Azure Account, Axure Functions, Azure Resources, PowerShell, Remote-WSL. This cleared the original error - but now I cannot get the debugger to start on either BreakPoints or Wait-Debugger after triggering the specific function. As a result, I have NO debugging experience until I figure out the issue.

[louis77]

Adding my five cents to this issue. I experience the same problem with the most recent versions of VS Code and the Azure functions extension. Restarting the debugging session breaks it with an error message "There is no process with the given ID". I must wait for 3-5 seconds until I can successfully restart debugging with F5.

I just started with Azure Functions and this makes it cumbersome to develop.

Versions:

• Windows 11
• VS Code 1.60.2
• Azure Functions Extension 1.002.221
• Azure Core tools ("func") 3.0.3785

[ejizba]

This could be related to PowerShell/PowerShellEditorServices#1295. The original comment describes "sluggishness and dead locks" which is representative of the comments in this issue, right? See this comment for latest update and how this affects VS Code: PowerShell/PowerShellEditorServices#1295 (comment)

It appears the (large) PR linked to that issue is actively being worked on: PowerShell/PowerShellEditorServices#1459