Files
sdk/pkg/dds
Danny Tuppeny 4d1b418230 [dds/dap] Fix breakpoint resolution races when there are multiple isolates
When there are multiple isolates, we may get breakpoint responses/events like this:

- Request/Response to add breakpoint to Isolate 1
- Request/Response to add breakpoint to Isolate 2
- BreakpointAdded for Isolate 1
- BreakpointResolved for Isolate 1
- BreakpointAdded for Isolate 2

Because Isolate 2 did not load the script, the last breakpoint was never resolved. However because the breakpoint ID matched, we would forward this event to the client and un-resolve the previously resolved breakpoint. This would result in odd behaviour in VS Code.

Additionally, the VM may return the same BM breakpoint ID for what the client thinks are two breakpoints (they are on different lines, but resolve to the same location) so when we get a resolved breakpoint, we need to handle both:

- Client breakpoints that have already been transmitted
- Future client breakpoints that may resolve to this same VM breakpoint

The previous code assumed that a BreakpointResolved event could be handled just once. Either for an existing breakpoint, or a future one.

This change swaps from storing queued events to storing the resolution information for each breakpoint, and it does this even if there was an existing breakpoint (in case the breakpoint is reused in future).

Fixes at least some of https://github.com/Dart-Code/Dart-Code/issues/4598

Change-Id: I53b92debfaa0c8f538dc8d67966854bb89634708
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311480
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
2023-06-27 14:54:10 +00:00
..
2023-06-02 19:07:39 +00:00
2021-04-07 10:28:38 +00:00
2022-02-14 14:06:34 +00:00
2022-07-12 19:35:22 +00:00

pub package package publisher

A package used to spawn the Dart Developer Service (DDS), which is used to communicate with a Dart VM Service instance and provide extended functionality to the core VM Service Protocol.

Functionality

Existing VM Service clients can issue both HTTP, websocket, and SSE requests to a running DDS instance as if it were an instance of the VM Service itself. If a request corresponds to an RPC defined in the VM Service Protocol, DDS will forward the request and return the response from the VM Service. Requests corresponding to an RPC defined in the DDS Protocol will be handled directly by the DDS instance.

SSE Support

For certain web clients it may be preferable or required to communicate with DDS using server-sent events (SSE). DDS has an SSE handler listening for requests on /$debugHandler.

SSE and package:vm_service example

import 'package:sse/sse.dart';
import 'package:vm_service/vm_service.dart';

void main() {
  // Establish connection with DDS using SSE.
  final ddsChannel = SseClient('${ddsUri}\$debugHandler');

  // Wait for ddsChannel to be established
  await ddsChannel.onOpen.first;

  // Initialize VmService using the sink and stream from ddsChannel.
  final vmService = VmService(
    ddsChannel.stream,
    (e) => ddsChannel.sink.add(e),
  );

  // You're ready to query DDS and the VM service!
  print(await vmService.getVersion());
}