Al: Stopping the debug session does not stop the bc session

[mjmatthiesen]

Describe the bug
Debug a session. Hit a breakpoint. Press stop. Enjoy the database locks that exist for X minutes because stop doesn't correctly release the session. The session is now stuck as if I was still debugging / waiting on continue. But I hit stop and would expect a "execution stopped by debugger" bubble up.

To Reproduce
See above description.

Expected behaviour
Release the session while stopping the action like it used to in older version.

Screenshots

5. Versions:

• AL Language: 6.1.352568
  
• Business Central: Version: US Business Central 16.5 (Platform 16.0.15884.17483 + Application 16.5.15897.16301)

[dtkb]

Aha, that might explain something weird I've been seeing, although that was against old BC15

[NKarolak]

Same (?) here, while I was debugging BC15 onPrem. I've restarted the service after it.

[mjmatthiesen]

So it's likely an issue with the AL Language, not BC itself.

I modified the original to make it clearer that the debugger isn't releasing the session, thus leaving locks that occurred while the debugger was paused.

[kalberes]

"Debug a session" : What exactly do you mean? Launch or Attach? Launch should possibly close the session, if it can (not always possible). But the attempt should be made and that is a bug.
Attach should never do that.

[dtkb]

At least for me, I got this when using "Start debugging" (Launch?) - am not using Attach.

In my case it was simple things like an XMLport getting a No Series Line with a lock to modify it, then erroring somewhere between that and the XMLport finishing, and me stopping the debugger - which didn't seem to release the lock, since next time around I got told the No Series Line table was locked and therefore had to restart the NST to continue.

[mjmatthiesen]

"Debug a session" : What exactly do you mean? Launch or Attach? Launch should possibly close the session, if it can (not always possible). But the attempt should be made and that is a bug.
Attach should never do that.

The only two actions I use are "Publish with debugging" (f5) and "Debug without publishing" (ctrl shift f5). It is set to launch. Here's my launch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "al",
            "request": "launch",
            "name": "Microsoft cloud sandbox",
            "startupObjectId": 23044601,
            "startupObjectType": "Page",
            "breakOnError": true,
            "launchBrowser": true,
            "tenant": "xyz",
            "environmentType": "Sandbox",
            "environmentName": "sandbox"
        }
    ]
}

What happens is that I stop on some breakpoint. If I then use the STOP action on the debugger, the session does not resume, does not receive an "activity stopped by debugger" message (paraphrasing). It just stays as is. It's just frozen. As if the debugger was still pausing the session. So far, I haven't found an instance where the debugger correctly stops the activity or allows the session to continue. It stays unresponsive.

[dtkb]

What happens is that I stop on some breakpoint. If I then use the STOP action on the debugger, the session does not resume, does not receive an "activity stopped by debugger" message (paraphrasing). It just stays as is. It's just frozen. As if the debugger was still pausing the session. So far, I haven't found an instance where the debugger correctly stops the activity or allows the session to continue. It stays unresponsive.

Yes, this is what I have seen too, this week on BC15 although it might affect later versions.

[shashiBssi]

started happening to me since the wave 2 al language compiler.previous compilers worked fine

[txeriff]

started happening to me since the wave 2 al language compiler.previous compilers worked fine

Same issue here.

[kalberes]

The timeout is unrelated. That is VSCode trying to be chatty, on the DAP disconnect.
The lock issue is there, since the debugger does not close the session it is debugging. The only remedy out of these kind of issues is that the debugger will close the session that it has started with the launch request.

[mjmatthiesen]

@kalberes

So are you saying if I launch another debug session, it will close the previous session? I'm not finding that to be true.

[VAIBHAV-NAGAR]

same issue

[kalberes]

No. What I am saying that the debugger does not close any sessions. And we will try to see if we can fix that, for launch requests. May not be possible though.

[shashiBssi]

i am not sure if you already know or not, but this was not the issue prior to wave 2 2020 release. if it will not be fix then what is the solution if each time tables are locked and do not allow to publish.

[mjmatthiesen]

No. What I am saying that the debugger does not close any sessions. And we will try to see if we can fix that, for launch requests. May not be possible though.

I'm not needing it to close the session as much as I am wanting it to kill the current action. For example, if I am debugging a posting routine and hit stop, that should stop the posting process and initiate the data roll back, the same way an error would. If I am making a call to an external API and hit stop, it should kill that request and feed "debugger stopped current process" back to the client. In the past, the session has continued, but the current thread was killed.

I hope that makes sense. It seems to have become an issue with AL Language 6.0, based on the other feedback in this thread. Mostly saas focused, so I don't test that much against older BC stuff.

[Jackeoh]

This is also leaving sessions active and locking which are not able to be stopped from the sessions screen.
Even if the debugger does not kill these sessions itself, we really need a way to be able to kill the session somehow. The locks are persisting for a long time, rendering the sandbox useless for 30-60 minutes.

[kalberes]

@Jackeoh
Killing sessions from TAC (Tenant Admin Center) will not work if that session is debugged. This feature is simply not supported (and it is not planned to be supported afaik). A debugger session has to be stopped from VSCode and not from the TAC. And that should work. I thought the issue we are discussing here is that this does not work properly
What you are talking about is a generic cancellation of sessions if they are in the middle of a transaction or a lock sequence.
Not debugger specific. Cancellation support today has its own limits.

@mjmatthiesen
The debugger cannot kill current actions. It will not stop posting routines, it will not rollback or commit transactions, etc, etc. It cannot do that safely. Not the current debug engine. This is not just throwing some exception and magic happens. Debugging is about hooking in to the AL execution for a given session. When debugging finishes it detaches from the current session, which will continue executing AL code as it is supposed so. We can think of this as an enhancement request, I do not say it does not make sense.
When you say "In the past, the session has continued, but the current thread was killed." do you mean the RTC based debug engine which had its own C/AL based invocation code base running as a dedicated singleton in the NST? What do you mean current thread? Threads running in the NST?

We can discuss if the debugger should close the session it has started with F5 on the other hand, which will close the web client (which the debug adapter has started in VsCode). Maybe good for some, bad for others. We can base it on launch configuration options. Many debuggers work on the premise that if the debugger starts a process it owns the process. The problem here is that closing a debugging may occur in non user scenarios too (slow connections, long pollings etc).
We will investigate what we can do, but probably we will not meet your request on abandoning transactions, actions etc.

[Jackeoh]

When you say "In the past, the session has continued, but the current thread was killed."

In the past, certainly within the last 6 months (I've not gone through old versions of BC/the AL language extension to check specific versions, sorry) if we pressed 'Stop' on the debugger in VS code the client would stop the action (for example posting) and the client would present the error 'The Debugger interrupted the current activity'.
However this occurred in the background, this is the ability we have lost recently and certainly has been present for AL & business central.

Having the debugger stopped in VS Code, but the server continuing to wait for the debugger to tell it to continue, and therefore locking the system until the server drops that session 40 minutes later, is extremely detrimental to the development process.

[mjmatthiesen]

When you say "In the past, the session has continued, but the current thread was killed." do you mean the RTC based debug engine which had its own C/AL based invocation code base running as a dedicated singleton in the NST? What do you mean current thread? Threads running in the NST?

No, not talking about the old cal debugger. That thing is basically dead to me. I work mostly with saas systems, so everyone is 16.x of some sort.

The debugger cannot kill current actions. It will not stop posting routines, it will not rollback or commit transactions, etc, etc. It cannot do that safely. Not the current debug engine. This is not just throwing some exception and magic happens. Debugging is about hooking in to the AL execution for a given session. When debugging finishes it detaches from the current session, which will continue executing AL code as it is supposed so. We can think of this as an enhancement request, I do not say it does not make sense.

I'm not pretending to know how the debugger did it, I can only tell you that it did in the past, before v6 at least. Maybe it wasn't safe, I really don't know. When I hit stop, the session in the browser would resume, but be hit with a "the debugger stopped the current action" or similar. Now when I hit stop, the session stays frozen. For all I know this had to do with using the legacy runtime, not sure when that switch happened in the AL Language extension.

Honestly, even if the session just continued when I hit stop, I could live with that. Right now it freezes the session and I have to wait for the session time out to try debugging again.

[shashiBssi]

All these years it was like as soon as i clicked stop on the debugger it stopped the current transaction and roll back.
There used be an error message "The Debugger stopped the current activity", this error message is now gone and the browser will stuck on "Working on it".

If we are going to continue like this, it is difficult as a developer.

Suppose i am debugging a posting , and i want to stop the current posting from the debugger , i cannot not do so, and i don't know what will happen to that transaction

[dtkb]

I find it quite mind-boggling that MS apparently didn't know how their own debugger was working until recently... which was pretty much just like the C/AL one did. Was it a mistake that stopping the debugger would stop the session with a message? Surely not. So many devs rely on that ability to find an error or breakpoint in a posting routine or other process, and stop it there. It's impractical enough to have to restart a local NST as workaround; on SaaS it's impossible.

[kalberes]

@dtkb
We know very well how the current debugger is working (as I remember, I implemented most of the current debug engine, also worked on the old debugger, but with time things certainly change ). Things get refactored, designs changed, mostly session handling adapting to SAAS. This has been accepted as a bug. That means that we will try to fix it as it was suggested here. Emphasis on "try".

[bc-ghost]

The fix for this issue has been checked in to the master branch. It will be available in the bcinsider.azurecr.io/bcsandbox-master Docker image starting from platform build number 18614.

If you don’t have access to these images you need to become part of the Ready2Go program: aka.ms/readytogo

For more details on code branches and docker images please read:
https://blogs.msdn.microsoft.com/nav/2018/05/03/al-developer-previews-multiple-releases-and-github/
https://blogs.msdn.microsoft.com/freddyk/2018/04/16/which-docker-image-is-the-right-for-you/

[mjmatthiesen]

The second link doesn't work. Is this being backported / form what version will it be available?

[atoader]

The fix has been checked in to the 17.x branch and will be available in 17.2. We will fix the links that the bots posts.