Edit: See repro in the comment below which may be easier to digest :-)

I'm investigating dart-lang/sdk#56367 which shows the debugger pausing on a breakpoint and then apparently resuming and showing as "Running" in the threads/call stack window unexpectedly. A second thread also shows as "Paused on entry" even though it was continued afterwards.

I don't currently have a repro for this, but I have a log of the DAP traffic that was captured alongside the video in that thread, which I have been through and annotated the important lines:

dap.txt

The video in dart-lang/sdk#56367 starts the debug session at approximately 0:10 in, which corresponds with approximately [3:14:12 AM] in the log file.

The video/log shows:

• The user starts the debug session (0:10, 3:14:12 in log)
• A breakpoint is triggered (0:26 in video, 3:14:26 in log), the call stack correctly shows Thread 1 paused at breakpoint, Thread 2 running
• The debugger mysteriously is unpaused (0:26 in video), the call stack now shows Thread 1 as running (it is not), Thread 2 as "Paused on entry" (it is not, it has already resumed and VS Code already showed this in the past)
• The user tries clicking the Pause button (0:33 in video, 3:14:34 in log) but at this point, things are broken

There is nothing in the DAP traffic to ever show Thread 1 unpausing after hitting the breakpoint, nor Thread 2 becoming paused-at-entry again. I feel like VS Code may somehow be applying a stale state of the call stack view from the past. There are lots of threads/call-stack requests for different threads ongoing - is it possible that one of them completes and then updates the state using information from before the request was sent?

I will post back if I can repro this, but I'm hopeful that with the video/log and info above, someone with knowledge of this code might understand what could be happening.