-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(app): ensure only one RPC connect request can go out at once #5322
Conversation
Codecov Report
@@ Coverage Diff @@
## edge #5322 +/- ##
===========================================
+ Coverage 47.27% 64.20% +16.92%
===========================================
Files 885 1077 +192
Lines 13331 32130 +18799
===========================================
+ Hits 6302 20628 +14326
- Misses 7029 11502 +4473
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
overview
This PR patches a couple weird usability issues with the RPC client/server interaction. The RPC server is a broadcast server; it will issue messages to all connected WebSockets, and it does not care if the same client establishes multiple WebSockets.
On the app end, if the client creates multiple connections to the RPC server, weird things can and do happen in the app state because it's not built to handle this. In lieu of messing around with the RPC server, which is generally too dangerous to touch without good reason / care, this PR adds multiple layers of protection on the client side to prevent multiple RPC connections from being established simultaneously:
In addition to the buttons getting disabled, this PR adds a spinner state to the main "connect" button when the request is in-flight. While the toggle is fully disabled when a request is in flight, I chose not to gray it out. My reasoning behind this choice was:
Closes #5241, closes #5307
longer term plans
In the long term, the RPC server will be replaced. Clicking the "connect" button will, instead of doing this whole RPC handshake + serialization + deserialization dance, make a single HTTP request to lock the robot control. Further seeding of state once control has been granted will happen in the background over multiple HTTP requests, with the UI gracefully updating as those requests come back
changelog
review requests
risk assessment
Medium