Losing VS code debugger connection after Fusion 360 September update

[thomasa88]

I'm having troubles with debugging add-ins after the September 2020 update (2.0.8950). (I'm also having problems with scripts, but I don't do much scripts, so let's start with add-ins).

I changed from the 2019.something Python extension in Code to the latest version, to even get started. I have also tried moving to 2020.8.109390, as it was recommended in another thread.

I can start Debug from Fusion 360 and it launches Visual Studio Code. I then run my add-in using F5 (It took a while before I figured out that the debugger will no longer break at start. I think I like this way. Just got used to the other one.). I re-run my add-in a few times using Ctrl+F5 and suddenly I get problems with the debugger connection.

Edit: OK, I tested some more, and it seems that if I accidentally press F5 things get messed up. I get errors as soon as I press Ctrl+F5 again. I guess Code tries to set up an extra connection. This is too easy to do.

Problems look like this:

First Ctrl+F5:

Trying ctrl+F5 again: Nothing happens (Maybe the session is stopped here).

Trying F5:

Then I go into Fusion and stop the add-in and try to debug again:

Looking in Code, I don't see any sessions(?). The status bar is blue (not attached) as well.

Closing all VS code instances does not help. I have to restart Fusion 360.

It seems I might have to close VS code as well, to not have stale data(???). At least when I tried just now, only restart Fusion, VS code could not connect after I clicked Debug in Fusion. Actually, right now, it seems that my Fusion 360 cannot even launch VS Code. It shows the command line window and then nothing happens..

Is there a better way to reset the state in Fusion? Is it possible to "block" this from happening?

PS. Try typing a message while launching Fusion several times. I knew it stole focus, but it seems to also get my Ctrl key activated somehow (pressing N while typing and Fusion launching, I got a new window in Firefox). I am running through remote desktop.

[pludikar]

@thomasa88 

Did you ever find an answer to this? 

I know it's been a couple of years since you posted and there have been a lot of F360 updates since then.  On the whole, the debugging connection is relatively stable (definitely significantly more stable that is was when you posted).  However, during my Add-in development I occasionally get the same loss of communication issue - I think it's often associated with some kind of bug that I introduce in my code, that then becomes irrecoverable.  Typically, the only way to recover is to shut down both VSC and F360 and restart - which is a bit of a pain.  A cleaner approach would be helpful (If anyone from AD is listening!)

Peter

[BrianEkins]

You're correct that the debugging and stability of working with the API using VS Code have improved significantly. However, this is one problem that still comes up. I know I run into it occasionally. The problem is figuring out what causes the problem. The developers need a way to reproduce the problem to debug why it's occurring. I know they've tried in the past, but without being able to see the problem occur, it's like shooting in the dark, and even if they make a change, there's no way to verify that it fixed anything.

So, if you can determine a set of steps that consistently causes the problem, please report it. Even though I sometimes run into the problem, I haven't been able to do that, so it's not as simple as it first sounds.

[pludikar]

@BrianEkins 

Thanks - It's helpful to know that I'm not alone.  I totally appreciate that not having a repeatable set of conditions makes it really hard to find a solution.  If my memory was as agile as it was many years ago it would be easy to reproduce, but alas it's not.  I'll endeavor to keep better track of what happened before the connection is lost.

Although saying "connection is lost"  is actually not precise.  It's more that the connection becomes persistent, but the VSC debugging panel that controls stepping, reset, disconnect etc. disappears and consequently you can't force a disconnect or reset from either VSC or F360 end.  F360 end is locked out because it's being held in a break point by VSC.  It would be nice to have a way of injecting a disconnect or reinstating the panel to force a disconnect - aka an emergency button.

Peter 

[pludikar]

Just lost connection again.  I suspect that this problem may be related to a memory leak.  I'm leaning that way because I can debug for hours and everything works reliably.  Then without any specific action or error on my part, the connection debug dialog disappears after clicking restart, but at the same time a message from VSC appears saying the attached process already exists.

I have a connection debug log (attached) - which doesn't actually say too much 

9 Client <-- Adapter:
{
    "seq": 4,
    "type": "event",
    "event": "debugpyWaitingForServer",
    "body": {
        "host": "127.0.0.1",
        "port": 54213
    }
}
17 Client <-- Adapter:
{
    "seq": 5,
    "type": "response",
    "request_seq": 2,
    "success": false,
    "command": "attach",
    "message": "Server[pid=12476] is already being debugged."
}

 pid 12476 is the main F360 process.

In this particular case I am able to interact with F360, and I'm ostensibly able to stop the debugging process (Add-in stop), which removes the * by the AddIn.  However, when attempting to debug - I get "there is already an active debugging session" - this is after I close down VSC!

using apiDebug commands - I get no eventHandlers, no relevant AddIn and no Objects.

Not sure that this helps.  If you have any suggestions I can attempt to explore from my end, I'd be happy to try.

Peter

[infoTF5PA]

I can recreate this consistently. If my code is stopped by a "ui.messageBox..." and I press F5 or Ctrl-F5 debugging is no longer possible, reporting the error message you documented. The only workaround I have found is to close and restart Fusion. There are other ways to get into this state, I haven't documented them yet.

With such an "easy" albeit annoying work around, I would be inclined to believe this is occuring much more often and just not being reported.

Until there is a real fix, it would be nice to have a feature that will attempt to close any existing debugging session/connection as a "fail safe" measure. Four (4) years and this still has not been addressed (that I could find)...