-
Notifications
You must be signed in to change notification settings - Fork 4k
Teach WebsocketConnection how to wait on an external auth token #5728
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
Conversation
b9c6e70 to
f431fb6
Compare
f431fb6 to
f8023ad
Compare
369c5cb to
6b3b257
Compare
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.
I think this looks good, but to be honest the complexity of this host-communication machinery makes it fairly impenetrable to my wee brain.
I wonder if withHostCommunication just shouldn't be a React thing at all.
frontend/src/hocs/withHostCommunication/withHostCommunication.test.tsx
Outdated
Show resolved
Hide resolved
frontend/src/hocs/withHostCommunication/withHostCommunication.tsx
Outdated
Show resolved
Hide resolved
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.
Not a criticism of your PR, but this whole class is sooooo hairy. It feels essentially write-only at this point.
I feel like we should prioritize a withHostCommunication refactor in the near-near future. (Should it even be a React component?)
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.
Yeah, agreed. I'd support seeing if we can get this made an official Q1 goal given that this code is changing far more frequently than I would have expected it to when I first noticed it was pretty hairy
6b3b257 to
23648c3
Compare
kmcgrady
left a comment
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.
I left some comments and questions just to solidify my understanding.
* develop: Change workers balancing logic for e2e tests to always cover all specs (#5865) Up version to 1.16.0 (#5852) Stop installing pip-tools (#5854) Add eslint no relative import paths plugin to pre commit hooks (#5839) Docs: move note to `experimental_allow_widgets` param description (#5843) Update element docstrings for colored text support (#5831) Add remark-directive plugin (Support for colored text in markdown) (#5774) Teach WebsocketConnection how to wait on an external auth token (#5728) Turn on streamlit theme for altair and plotly (#5796) Fix markdown headers spacing (#5829) Update error message and docstring in st.map (#5792) Remove unnecessarily methods from DeltaGenerator (#5824) Resolve vega-tooltip to later version (#5825) Easter Egg (#5817) Update Exception Layout to avoid overflow (#5700)
📚 Context
There's currently a race condition that appears when using an external auth token passed to the
streamlit web client. The race is between the auth token actually making it to the iframed streamlit
app before it attempts to establish a websocket connection. What generally happens is that the first
attempt to establish the websocket connection is done without having received the token, which
results in a failed connection attempt. The next retry about 500ms later then succeeds (most
of the time, although the asynchronous nature of all of this makes it hard to guarantee when the
token is received), but both the extra round-trip and notable startup delay are annoying.
This PR fixes this problem by adding a new field to the
/st-allowed-message-originsresponse body.The
useExternalAuthTokenfield (which for now will always be set toFalsein the pure open sourceworld) is used by the client to decide whether to wait for an auth token to be received from the parent
frame before attempting to establish a websocket connection to the Streamlit server.
If
useExternalAuthTokenisFalse, the client immediately attempts to establish a websocketconnection. Otherwise, it waits until a promise resolves to the auth token before proceeding.
What kind of change does this PR introduce?
🧪 Testing Done