Cache js breakpoint ids and reuse them when adding new breakpoints

[iinozemtsev]

Internally, there are two different code paths to trigger hot restart:

1. Via connected debugger, triggering _hotRestart funciton in dwds_vm_client.dart. This codepath removes existing breakpoints and blocks main script execution (by passing pauseIsolatesOnStart into dartHotRestartDwds) until the connected debugger re-adds breakpoints.
2. Via in-app shortcut in injected UI, which just calls dartHotRestartDwds directly. This codepath does not clear breakpoints and does not block main startup.

The second flow with in-app triggered restart is currently doesn't work as intended:

1. Chrome breakpoints aren't cleared, but the attached debugger still gets an isolate start event
2. It tries to set all breakpoints in a new isolate, and sends add breakpoint commands
3. Chrome API returns an error that the breakpoint exists, and the error is propagated back to DAP server, which sends a set breakpoint error notification to an IDE.
4. The IDE thinks that the breakpoint is "unconfirmed", and hides it from the UI completely.

As a result, the user does not see the breakpoint, but it's there, in Chrome debugger state, and the execution stops on it, and there's no way for user to remove it (except for clearing all breakpoints by the restart/reload from an IDE, which clears chrome debugger state).

The CL attempts to fix it by caching chrome breakpoint ids by js locations, so that when the debugger adds a breakpoint resolving to the same js location, it gets back the same js breakpoint id.

• Thanks for your contribution! Please replace this text with a description of what this PR is changing or adding and why, list any relevant issues, and review the contribution guidelines below.

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

Note: The Dart team is trialing Gemini Code Assist. Don't take its comments as final Dart team feedback. Use the suggestions if they're helpful; otherwise, wait for a human reviewer.

[iinozemtsev]

did you have a chance to look at this pr?

[bkonyi]

I think this seems reasonable to me. @Markzipan, can you take a look too?

[Markzipan]

@nshahan has more context about hot restart breakpoints - adding them here

[nshahan]

@iinozemtsev
Do you have a reproduction for the problem and potentially use it in a test?

I believe this new implementation that blocks running main while the debugger is manipulating breakpoints was added by @srujzs. While adding support for breakpoints after a hot reload he found correctness issues and inconsistencies with the current approach. Do you think it would be possible to utilize the same logic when restarting from the injected UI? I think this would be preferable for multiple reasons:

• Less Hot Restart flows for us to support and manually test every time we make a change.
• Without blocking main there are still issues with this approach since the app can be running before all breakpoints have been set. We potentially have a race condition that allows executing through lines that should and will eventually have a breakpoint on them.

[iinozemtsev]

potentially use it in a test?

if there are existing tests which wire dev extension, webdev server with dwds, and a dap client, I think adding a test would be relatively straightforward, otherwise I think it's too big task to chew for me at the moment.

I'll try to take a look tomorrow if there's an easy way to converge the in-app restart path into dwds_vm_client.

[iinozemtsev]

I've sent cl/840666025 internally to demo alternative approach just for quicker prototyping, I can turn that into a real PR if LG.