vscode: Allow debug extensions to show diagnostic information in the breakpoints view

👍

I was bugging @connor4312 for unbound breakpoints in a project which has a wrong webpack output config. Due to the misconfig, the source maps are wrong. It would be helpful the unbound breakpoint has some tooltip/hover as suggested above and send to me a diagnostic/troubleshooting view.

I like this too! and if we want to make this stand out a bit more, we could append it to the header’s label. IMO this makes sense because the icon is always visible like the label, and not only on hover.

And @connor4312 said that we should make it clear that only the extension that owns the DebugSession should use this API. I won’t try to restrict any other extension from calling it and possibly wiping out the message that the DA extension set, but that would basically be misuse of the API, any API can be misused.

think this looks ok, any thoughts?

I like how it looks.

The common way for DA’s to communicate is to use a custom DAP call and then onDidReceiveDebugSessionCustomEvent in the EH.

going on a debug session makes the most sense to me. Probably one message per session.

I think we have 4 options, 3 DAP-based and 1 extension-API based:

• DAP: the SetBreakpoints request returns Breakpoint objects with information about the verified or unverified breakpoints. Every Breakpoint object has a message property with this description: “An optional message about the state of the breakpoint. This is shown to the user and can be used to explain why a breakpoint could not be verified.” Using this message would require a diagnostic information UI per breakpoint (as pointed out by @connor4312 this approach is too fine grained for the breakpoint diagnostic information provided by js-debug).
• DAP: as suggested by @roblourens we could introduce a message property on the SetBreakpointsResponse but this request is still per resource (file). So multiple messages could be returned when starting debugging and a UI would have to deal with that. So this is again too fine grained for the breakpoint diagnostic information provided by js-debug.
• DAP: we could introduce a new DA capability that provides a single piece of diagnostic information to the client and the client would show that whenever unverified breakpoints exist for a debug session. Since this information is static and declarative the DA would not have to actively show/hide it. Instead the client could do the “right thing” (even after #126608 has been fixed). Currently we do not support markdown strings in DAP. So if we deem markdown as important then we would have to design a markdown-story for DAP.
• API: showBreakpointsInfoMessage would supply the client with a markdown string whenever breakpoints are amiss. The client would show the information with the same logic as option 3. Here we would not have the “markdown” problem, but instead the problem that the extension does not have easy access to information about unverified breakpoints (because the DA is a separate process).

@roblourens @connor4312 did I miss anything?

My preference is option 4.