You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make it clearer when "Waiting for current test to finish" when stopping a debug session #2380
Can anyone reproduce the issue, that you need to click the stop button of the debug session two times to actually end it? I am also using a short cut for ending the debug session, where I have this behavior to - I must hit the short cut two times to end the session.
Does it only happen when you're stopped at a breakpoint when you click Stop? Could you capture a log?
The first time you click stop, it will send a message to try and shut down cleanly. The second time it basically forces a quit - which could result in leaving orphaned processes around if they don't clean up.
It's normal for there to sometimes by a (smallish) delay between the first click and it stopping, depending on what type of app and how much there is to shut down (eg. things like web server and Chrome in the case of a web app), but shouldn't be too long. I don't think the VS Code UI is particularly great here, as it's not clear that the second click might result in orphaned processes.
No it doesn't matter if I am stopped at a breakpoint or not. Also for reproducing the log I waited a long period between the first and second click (min 10 sec).
Oh, I overlooked that it was a test in the video. What's happening here is that package:test prints this (this first line should appear in the debug console, but I guess you don't see it if that's not visible):
> [9:50:09 PM] [PubTest] [Info] [Tests] <== Waiting for current test(s) to finish.
> [9:50:09 PM] [PubTest] [Info] [Tests] <== Press Control-C again to terminate immediately.
It does this because if it just terminates, it might leave state around (so it wants to finish the test and run tearDowns). I don't think we can change this behaviour, but maybe when that text is output, we should show a progress indicator (so you'll always see it) so you know what's happening?
changed the title [-]Must click stop button 2 times, to stop debug sessions[/-][+]Make it clearer when "Waiting for current test to finish" when stopping a debug session[/+]on Apr 22, 2020
to follow up on this. I recreated the initial scenario, just with the debug console open: https://imgur.com/Enqjr1a
I try to explain the scenarios I would expect from a user perspective:
1:
Start the test
Debugger stops at breakpoint
I click on stop
Pop up apears "Waiting for current test(s) to finish"
vscode runs teardown/cleanup whatever needs to be done
debugging session stops
2:
Start the test
Debugger stops at breakpoint
I click on stop
Pop up apears "Waiting for current test(s) to finish"
I don't care click stop again
debugging session stops
Current Senario (You can see this in the imgur):
Start the test
Debugger stops at breakpoint
I click on stop
Pop up apears "Waiting for current test(s) to finish" (Or in the debug console right now)
Nothing happens
I manually click stop the second time
debugging session stops
Is the current behavior really, the intended one?
BTW: The behavior happens while starting a debug session on android (didn't tested ios). When I click on the stop button, while the application is launching, nothing happens it just continues launching. The second click stops the launching. Once the application launched on the device one click is enough.
I think the issue here is the breakpoints. When you're paused at a breakpoint, the test will never finish, and therefore there will never be a graceful shutdown.
We already remove all breakpoints and resume all threads when disconnecting from an attached process, so I think probably we should do this also during normal shutdown. It feels a bit weird to resume code (if you're paused on a breakpoint above a File.delete and you click Stop, you probably wouldn't expect it to delete the file, but I'm not sure there's a better fix unless package:test allowed a way to terminate the test but still run cleanup - cc @jakemac53).
Ok, we now remove breakpoints/unset exception pause mode/resume all threads during termination. This solves the issue above where you click Stop when at a breakpoint in a test.
The behavior happens while starting a debug session on android (didn't tested ios). When I click on the stop button, while the application is launching, nothing happens it just continues launching.
This one sounds like a different issue (but one I think I've raised before with Flutter, but cannot find right now). Could you capture a log and file a separate bug here in Dart-Code and I can take a look? Thanks!
Activity
DanTup commentedon Apr 21, 2020
Does it only happen when you're stopped at a breakpoint when you click Stop? Could you capture a log?
The first time you click stop, it will send a message to try and shut down cleanly. The second time it basically forces a quit - which could result in leaving orphaned processes around if they don't clean up.
It's normal for there to sometimes by a (smallish) delay between the first click and it stopping, depending on what type of app and how much there is to shut down (eg. things like web server and Chrome in the case of a web app), but shouldn't be too long. I don't think the VS Code UI is particularly great here, as it's not clear that the second click might result in orphaned processes.
HerrNiklasRaab commentedon Apr 21, 2020
Hey @DanTup,
No it doesn't matter if I am stopped at a breakpoint or not. Also for reproducing the log I waited a long period between the first and second click (min 10 sec).
my logs are attached:
logsvscodedebugstop.zip
DanTup commentedon Apr 22, 2020
Oh, I overlooked that it was a test in the video. What's happening here is that
package:testprints this (this first line should appear in the debug console, but I guess you don't see it if that's not visible):It does this because if it just terminates, it might leave state around (so it wants to finish the test and run
tearDowns). I don't think we can change this behaviour, but maybe when that text is output, we should show a progress indicator (so you'll always see it) so you know what's happening?[-]Must click stop button 2 times, to stop debug sessions[/-][+]Make it clearer when "Waiting for current test to finish" when stopping a debug session[/+]DanTup commentedon Apr 22, 2020
This will now show even if the Debug Console is not visible.
HerrNiklasRaab commentedon Apr 22, 2020
Hey @DanTup
to follow up on this. I recreated the initial scenario, just with the debug console open: https://imgur.com/Enqjr1a
I try to explain the scenarios I would expect from a user perspective:
1:
2:
Current Senario (You can see this in the imgur):
Is the current behavior really, the intended one?
BTW: The behavior happens while starting a debug session on android (didn't tested ios). When I click on the stop button, while the application is launching, nothing happens it just continues launching. The second click stops the launching. Once the application launched on the device one click is enough.
DanTup commentedon Apr 22, 2020
I think the issue here is the breakpoints. When you're paused at a breakpoint, the test will never finish, and therefore there will never be a graceful shutdown.
We already remove all breakpoints and resume all threads when disconnecting from an attached process, so I think probably we should do this also during normal shutdown. It feels a bit weird to resume code (if you're paused on a breakpoint above a
File.deleteand you click Stop, you probably wouldn't expect it to delete the file, but I'm not sure there's a better fix unlesspackage:testallowed a way to terminate the test but still run cleanup - cc @jakemac53).DanTup commentedon Apr 22, 2020
Ok, we now remove breakpoints/unset exception pause mode/resume all threads during termination. This solves the issue above where you click Stop when at a breakpoint in a test.
This one sounds like a different issue (but one I think I've raised before with Flutter, but cannot find right now). Could you capture a log and file a separate bug here in Dart-Code and I can take a look? Thanks!