Create a DTD service for managing connected apps

[kenzieschmoll]

Background

The Dart Tooling Daemon (DTD) is either started by DDS / DevTools server, in the case where an app is started from the CLI, or an IDE plugin / extension (VS Code, Android Studio, or IntelliJ), in the case where an app is started from the IDE. This means that DTD may be connected to a development workflow that has one or many running apps.

For DTD clients like DevTools and the new Dart Tooling MCP Server, a client may need to fetch the list of active debug sessions (the running Dart / Flutter apps). In the case where DTD is started from a 1P supported IDE (VS Code or Android Studio / IntelliJ), the IDE provides an EditorService from which a client can get the list of active debug sessions, and therefore the list of the active VM Service URIs. However, in the case where a 1P supported IDE did NOT start DTD, this service will be unavailable and there is no way to get the VM service URI of the running app(s).

The following is a proposed solution to this problem, allowing DTD to have awareness of the connected Dart & Flutter applications that the DTD clients are interacting with.

Proposed solution

Create a new service ConnectedAppService directly in DTD that provides the methods:

• [Protected] void registerVmService(String uri)
• List<String> getVmServiceUris()

[Protected] here means that the only DTD client that started DTD (either the IDE or DDS / DevTools server) should be able to call this method. We can use the same client secret that we require for the setIDEWorkspaceRoots method.

The ConnectedAppService can maintain a set of VmService objects for the VM service URIs that have been registered, which will allow the service to automatically clean up VmService instances when they are shutdown.

[OPTIONAL] Instead of (or in addition to) getVmServiceUris(), we could implement a stream for the VM Service URIs that DTD clients can subscribe to. Upon a client subscribing to this stream, all the current VM Service URIs should be sent. The stream should be updated with vmServiceRegistered and vmServiceShutdown events so that the client can update its set of URIs. This may not be necessary since the client can just request getVmServiceUris() whenever an operation needs to know about the current set of VM service instances.

Implementation plan

1. Build the ConnectedAppService in DTD. CC @bkonyi
   • Done - https://dart-review.googlesource.com/c/sdk/+/427568
2. [DDS] For the case of an app started from the CLI (dart or flutter), call the new method ConnectedAppService.registerVmService. This should be called whenever DDS (or DevTools server inside DDS) is responsible for starting DTD.
   • DDS - https://dart-review.googlesource.com/c/sdk/+/429760
   • DevTools server - Register and unregister VM service connections on DTD from the DevTools server flutter/devtools#9211
3. [Dart-Code extension] Call the new method ConnectedAppService.registerVmService when a new debug session is started. CC @DanTup
   • Register VM Services with DTD using new registerVmService/unregisterVmService methods Dart-Code/Dart-Code#5526
4. [IntelliJ Plugin] Call the new method ConnectedAppService.registerVmService when a new debug session is started. CC @jwren @pq
   • Call the new ConnectedAppService DTD methods when VM Service instances are started / stopped flutter/flutter-intellij#8261
5. In the Dart Tooling MCP Server (the first DTD client that will be using this new service), initially call ConnectedAppService.getVmServiceUris only when the EditorService.getDebugSessions method is not available. This will ensure that the Dart Tooling MCP Server is backwards compatible with older IDE plugin / extension versions. After some safe time period (12-18 months?), switch over to using ConnectedAppService.getVmServiceUris exclusively. CC @jakemac53

[jakemac53]

Which thing will be in charge of calling registerVmService for the standalone flutter/dart run case?

[bkonyi]

Which thing will be in charge of calling registerVmService for the standalone flutter/dart run case?

Probably DDS, since it's responsible for starting DTD when we're running from the CLI.

[bkonyi]

@kenzieschmoll what's the priority of this work? The services team is already committed to a bunch of ongoing efforts so I'd like to figure out if we need to reprioritize anything.

[jakemac53]

Probably DDS, since it's responsible for starting DTD when we're running from the CLI.

SGTM, @kenzieschmoll can you add that to the implementation plan?

[kenzieschmoll]

@kenzieschmoll what's the priority of this work? The services team is already committed to a bunch of ongoing efforts so I'd like to figure out if we need to reprioritize anything.

We are still determining the priority here. I would consider this P2 for now, but we will know more over the coming weeks WRT whether the priority should be raised.

Probably DDS, since it's responsible for starting DTD when we're running from the CLI.

SGTM, [@kenzieschmoll](https://github.com/kenzieschmoll) can you add that to the implementation plan?

Done.

[DanTup]

In the Dart Tooling MCP Server (the first DTD client that will be using this new service), initially call ConnectedAppService.getVmServiceUris only when the EditorService.getDebugSessions method is not available.

Should this be the other way? When IDEs provide both services, wouldn't it be better to always use the new one (so that the behaviour doesn't (potentially) change at the time that use of getDebugSessions is removed?).

btw - who is starting the MCP server and when? (I'm wondering if there may be any race here because the getDebugSessions service is registered by the IDE - is it possible the MCP server checks for it just before it is registered?)

[jakemac53]

Should this be the other way? When IDEs provide both services, wouldn't it be better to always use the new one (so that the behaviour doesn't (potentially) change at the time that use of getDebugSessions is removed?).

The problem I think is that ConnectedAppService.getVmServiceUris may exist, but the IDE might not be supporting it yet. We could do something where we only try Editor.getDebugSessions if there are no VM service uris registered though.

who is starting the MCP server and when

The clients (cursor, Gemini code assist, copilot, etc) will be starting it - so this is dependent on the situation. But the MCP server doesn't connect to anything until the user actually tries to take an action that requires it, at which point they are prompted for a DTD Uri, which should have been alive for some time already. We can also just listen for it to get registered.

[DanTup]

The problem I think is that ConnectedAppService.getVmServiceUris may exist, but the IDE might not be supporting it yet.

Oh yeah, I was thinking about it being registered by the IDE.

Maybe one option would be to only register getVmServiceUris when the first VM Service is recorded (and then the server can just use whichever shows up first, or if both are available, always prefer the new one). I don't know if it's worth the extra complexity though.

But the MCP server doesn't connect to anything until the user actually tries to take an action that requires it, at which point they are prompted for a DTD Uri, which should have been alive for some time already.

Thanks - sounds like that's a non-issue then :-)

[kenzieschmoll]

An initial implementation of this service is here: https://dart-review.googlesource.com/c/sdk/+/427568. The service registers a single method registerVmService and it posts VmServiceRegistered and VmServiceUnregistered events on the ConnectedApp stream. VmServiceRegistered events are sent when the registerVmService method is called and VmServiceUnregistered events are sent when the VmService.onDone handler is called.

@DanTup are there edge cases here that this logic doesn't cover? One I thought of was if the IDE loses connection to the connected app. In that case the VM service would still be alive, and so the object on DTD would remain alive even though the IDE wouldn't have a connection to it.

Another case to think about is when DTD needs to restart but the apps in the IDE remain alive. In that case, the IDE should probably call the registerVmService methods again on the new instance of DTD.