[ DWDS ] Disconnect non-DDS clients when DDS connects #2671
Conversation
The native VM service disconnects all non-DDS clients when DDS connects in order to keep state consistent. DWDS was never configured to work this way and, instead, would not let DDS connect if there were already existing clients. This is fine most of the time, as DDS is typically the first client, but in cases where multiple DDS instances attempt to start at once (e.g., a simultaneous `flutter run` and `flutter attach`), this inconsistency prevents tools from falling back to using an already connected DDS instance, as seen in flutter/flutter#171758. Fixes #2399
Package publishing
Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation. |
There was a problem hiding this comment.
Sorry I don't understand what the context is here. Can you elaborate on what the other connected clients can be? What would the end user typically be doing to notice some client getting disconnected because a dds client connected? Do they have a path to recovery in that situation?
Not a problem, this is a bit of a niche DDS implementation detail. Basically, DDS presents itself as the VM service to clients, even though it's actually middleware. Since clients are connecting to DDS and not the VM service directly, DDS needs to be able to handle all of the VM service functionality that is client dependent, including sending service events to clients for streams they've listened to and service extension routing. If DDS is connected to a VM service and there's also other clients connected directly to the VM service, things can get into an inconsistent state. For example, the VM service itself won't know about service extensions registered by clients with DDS, so any clients connected directly to the VM service won't be able to invoke those service extensions. To prevent this, the VM service implementations have a special, private The native VM service has always disconnected non-DDS clients when this RPC is invoked. Before disconnecting a client, it first sends an event on the DWDS never actually implemented this behavior, and instead opted to throw an exception when This situation used to never happen. However, Dart-Code does have some scenarios where it runs |
|
I'm trying to land a bug fix as well here btw: #2673 and would like to put both these in the same bug fix version. Should I land that first or after this? |
That's correct. DDS was seeing an |
I'd like to get this change landed ASAP as it's one of our top crashers in the Flutter tool, so if I could land first I'd appreciate it :) Are you planning on cherry picking that change into Flutter by any chance? I'll need to create a hotfix release on top of |
|
Thanks!
Go for it! I'll land a separate bug fix version once you publish this one and update Flutter to use that.
No, this is purely just to get web socket hot restart working in Flutter, which isn't enabled in stable anyways. |
The native VM service disconnects all non-DDS clients when DDS connects in order to keep state consistent. DWDS was never configured to work this way and, instead, would not let DDS connect if there were already existing clients. This is fine most of the time, as DDS is typically the first client, but in cases where multiple DDS instances attempt to start at once (e.g., a simultaneous `flutter run` and `flutter attach`), this inconsistency prevents tools from falling back to using an already connected DDS instance, as seen in flutter/flutter#171758. Fixes #2399
The native VM service disconnects all non-DDS clients when DDS connects in order to keep state consistent. DWDS was never configured to work this way and, instead, would not let DDS connect if there were already existing clients.
This is fine most of the time, as DDS is typically the first client, but in cases where multiple DDS instances attempt to start at once (e.g., a simultaneous
flutter runandflutter attach), this inconsistency prevents tools from falling back to using an already connected DDS instance, as seen in flutter/flutter#171758.Fixes #2399