search

flutter / devtools

Performance tools for Flutter
https://flutter.dev/docs/development/tools/devtools/
BSD 3-Clause "New" or "Revised" License
1.56k stars 321 forks source link

Sync breakpoints between Debugger tab and VSCode #6146

Open johnpryan opened 1 year ago

johnpryan commented 1 year ago

Right now, setting a breakpoint in the Debugger tab does not set a breakpoint in VSCode. But when I set a breakpoint in VSCode it does show up in the Debugger tab. Is there a way to better keep breakpoints in sync?

DanTup commented 1 year ago

Right now I don't recommend using the debuggers from both at the same time (the debugger tab should be hidden when launching from VS Code - https://github.com/flutter/devtools/issues/1792 - although that wouldn't stop you connecting an external instance).

The main issue is that to avoid race conditions we have to make the app pause during a restart, so we can re-send breakpoints without them being missed if they were in code that ran at the start. This means that VS Code will:

This code assumes no other editor is doing the same thing at the same time (otherwise one might resume while the other is still sending breakpoints, and one will get a "not paused" error when trying to resume),

There's a new API to help coordinate this:

https://github.com/dart-lang/sdk/blob/master/pkg/dds/dds_protocol.md#requirepermissiontoresume

Both VS Code and DevTools will need to adopt it for it to work.

However, the focus there was just on fixing any races that come from the actions above. It is not intended to help sync breakpoints across editors. I think we'd talked about this in the past but it wasn't clear who would own each breakpoint once they are synced (and therefore who should be resetting them when the app reloads, etc.) so I think we decided VS Code would only ever show its own breakpoints and ignore any from other editors.

We could perhaps revisit this, but we'd need to consider how breakpoints are owned and who re-sends them. Last time I checked I don't think there was a way (once we'd sent another editors breakpoints into VS Code) to distinguish user-set versus another-editor-set breakpoints which might complicate it. (cc @bkonyi)

bkonyi commented 1 year ago

There's a new API to help coordinate this:

https://github.com/dart-lang/sdk/blob/master/pkg/dds/dds_protocol.md#requirepermissiontoresume

I'm pretty sure I originally implemented this in 2019, so I wouldn't call it new, just no one ever wired it up... 😅 Also, it looks like we never actually created VmService extension methods for those APIs, which we definitely should do...

We could perhaps revisit this, but we'd need to consider how breakpoints are owned and who re-sends them. Last time I checked I don't think there was a way (once we'd sent another editors breakpoints into VS Code) to distinguish user-set versus another-editor-set breakpoints which might complicate it. (cc @bkonyi)

I do vaguely remember this discussion, but I think a simple way forward would be to associate a VM service client's name with a Breakpoint. We already have a mechanism to name a VmService client using setClientName, so we could have DDS keep track of which client created each breakpoint and have it attach an extra owner property to all Breakpoint responses and events. This way clients can easily figure out which breakpoints they own and reset them without having to worry about breakpoints set by other clients.