Background: I'm attempting to implement actions that are run by the IDE when specific breakpoints are hit; Actions that are a bit more complex than the protocol provides (which is fine… these actions are purely IDE-specific and aren't really the concern of the adapter). They are actions like "show a specific view when a specific function breakpoint is hit" or "play a specific sound".

With the Stopped event, the reason field can denote that a thread stopped because of a breakpoint, function breakpoint, etc. However, I have been running into difficulty planning the best way to know which breakpoint the debugger hit with any accuracy.

Once the Stopped event arrives, it is possible to request the Thread that stopped, then its individual stack frames (and then even scopes). Then you can begin to correlate on which source line debugging stopped to a Breakpoint object that was returned from the adapter. But this only works as long as the adapter was able to provide the line parameter. This is likely to be returned for source breakpoints, but function breakpoints seem to be another matter (as not all adapters would likely be able to accurately resolve line / column information for a function purely by name when adding them.)

If this indeed is not directly possible right now, I'd like to propose something like a breakpointId attribute of the Stopped event, based on the IDs returned from the SetBreakpoints or SetFunctionBreakpoints requests. This way, the IDE can know exactly which resolved breakpoint was hit by the debug adapter. As far as my limited knowledge goes, this would still determine whether a source or function breakpoints was hit, as well.

It's also possible that I've entirely overlooked something in the protocol definition that makes this more clear or concrete. If so, I'd be very thankful for any clarification!