[Lldb-commits] [lldb] [lldb-dap] Adjusting startup flow to better handle async operations. (PR #140299)

[John Harrison via lldb-commits]

ashgti wrote:

> That said, does this actually solve the underlying problems? We know that VS Code sends the launch and attach request before configuration done. It's equally valid to not do that, and do things the way they're shown in the sequence diagram, where you set breakpoints, then configuration done, then launch or attach. Won't that still hit the same problem?

I think there are 2 specific problems that we have after ba29e60f9a2222bd5e883579bb78db13fc5a7588.

1. The pending request filter is somewhat fragile and for @da-viper use case of implementing support for [supportsDataBreakpointBytes](https://microsoft.github.io/debug-adapter-protocol//specification.html#Requests_DataBreakpointInfo) they're running into issues trying to respond to the `dataBreakpointInfo` request without access to a valid target but by not responding to the request, we're not getting `configurationDone`.
2. With the new launch flow, we're setting breakpoints before we've created a target, which is why I'm seeing us missing breakpoint events now when we used to not miss with `launchCommands`.

As for the sequence, the flow has 2 parallel tracks that are independently triggered. The overall flow is:

* After capabilities are returned from the initialize request trigger the `request launch` or `request attach`
* After adapter sends `event initialized`, trigger the `setBreakpoints`, `setFunctionBreakpoints`, `setExceptionBreakpoints `, `setDataBreakpoints`, etc. followed by `configurationDone`.

We're actually triggering the configuration flow by sending `event initialized` so we can adjust when that happens. Per the spec:

> the debug adapter is expected to send an [initialized](https://microsoft.github.io/debug-adapter-protocol/specification#Events_Initialized) event to the development tool to announce that it is ready to accept configuration requests. With this approach a debug adapter does not have to implement a buffering strategy for configuration information.

Maybe we should look at moving the `initialized` event to after we've responded to the `launch`/`attach` commands instead of buffering or making them async.


https://github.com/llvm/llvm-project/pull/140299