Allow for dumping service protocol information to a file on startup

[bkonyi]

Currently all tools wishing to connect to the service protocol need to scrape the URL and authentication codes from stdout. However, this isn't always possible or convenient (@DanTup mentioned some VSCode use cases that cannot rely on listening to stdout to get the service protocol information). The VM should provide a way to dump service protocol information to a file in a well known format that can be consumed by tooling (e.g., dart --observe --dump-service-info=service.json foo.dart).

Example format:

{
  "version": 1,
  "url": "http://127.0.0.1",
  "port": 8080,
  "authentication_code": "6iSIXM0fOBk=",
}

[bkonyi]

cc/ @zanderso would this functionality allow for us to enable authentication codes on Fuchsia?

[DanTup]

@DanTup mentioned some VSCode use cases that cannot rely on listening to stdout to get the service protocol information

To expand on this - our debug adapter currently owns the process (and streams) because we need to scrape the Observatory URI to connect the debugger. However we have no good way to let the user to then send input to stdin (so if they want to debug an interactive CLI app, they can't - Dart-Code/Dart-Code#99).

If we could get the info without needing to own stdout, then we can just spawn the process in a terminal and let them have full access to the streams themselves. Similar to the existing --pid-file option, for ex. dart --debugger-file=/tmp/somefile.json script.dart. Then we could just watch that file and read the debugger info from there (it could be deleted when the VM quits).

[zanderso]

Regarding Fuchsia, this would probably not reduce the amount of plumbing needed to get the auth codes where they need to go since the port is already being read out of a file.

[DanTup]

@bkonyi this looks great! In the sample at the top you included a version number, though that doesn't seem to be in the written file - do you think we should add it?

It would also be nice to suppress the "Observatory listening" text (if easy) when this flag is supplied before we start using it (so there's no danger of anything using the flag also depending on the output).

When testing, I also saw this:

vm-service: isolate(401215214933043) 'main' has no debugger attached and is paused at start. Connect to Observatory at http://127.0.0.1:8181/HCf6LrZjZIo=/ to debug.

I don't know what triggers this - is it if no debugger attaches within a certain period? (If so, what is that period? it seems like it could be racy if the IDE doesn't connect fast enough - though I've never noticed it show up in the console before).

[DanTup]

@bkonyi I presume the URI here is still the Observatory web app, and for the VM service we should change the protocol to ws://, append the token and then /ws? If so, is there value in adding a vmServiceUri field that is the full websocket URI to simplify clients (and make it easier for the VM to change this in future if desired)?

[bkonyi]

@bkonyi I presume the URI here is still the Observatory web app, and for the VM service we should change the protocol to ws://, append the token and then /ws? If so, is there value in adding a vmServiceUri field that is the full websocket URI to simplify clients (and make it easier for the VM to change this in future if desired)?

That's correct. I don't think we output the websocket URI since it's rather easy to build from the Observatory URI. If this is something you think would be useful, would you mind filing a separate issue to track it?

[DanTup]

Sure, will do. It's not difficult to build, but it'd be nice to have done in one place (I also wasn't sure if the Observatory web app went away and the VM only hosted a WS, whether that would change things here - whereas a specific WS URI wouldn't need to change). Thanks!

Edit: #40839