-
Notifications
You must be signed in to change notification settings - Fork 4k
Nicer handling of connection errors #11366
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
…ctual try, so it's not guaranteed to be correct.
🎉 Snyk checks have passed. No issues have been found so far.✅ security/snyk check is complete. No issues have been found. (View Details) ✅ license/snyk check is complete. No issues have been found. (View Details) |
✅ PR preview is ready!
|
| switch (dialogProps.type) { | ||
| case DialogType.ABOUT: | ||
| return aboutDialog(dialogProps) | ||
| return <AboutDialog {...dialogProps} /> |
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.
Just using proper Reacty syntax here.
frontend/app/src/App.tsx
Outdated
| showConnectionError(title: string, errorMarkdown: string): void { | ||
| LOG.error(errorMarkdown) | ||
| const newDialog: DialogProps = { | ||
| type: DialogType.CONNECTION_ERROR, |
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.
Previously, connection errors used the WARNING dialog type, but for this work I needed to know whether there was a connection error dialog open (not just any warning dialog) in order to rescind it. So I added a new type of dialog called CONNECTION_ERROR, and duplicated some of the word that handled the warning dialog.
| // to inform the host of connection error | ||
| const shouldSendClientError = | ||
| totalTries === THRESHOLD_FOR_CONNECTION_ERROR_DIALOG | ||
| const tooManyRetries = totalTries >= MAX_RETRIES_BEFORE_CLIENT_ERROR |
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.
Just some nicer variable names.
| export const PING_MINIMUM_RETRY_PERIOD_MS = 500 | ||
| export const PING_MAXIMUM_RETRY_PERIOD_MS = 1000 * 60 | ||
| export const PING_MINIMUM_RETRY_PERIOD_MS = 100 | ||
| export const PING_MAXIMUM_RETRY_PERIOD_MS = 2000 |
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 reduced these so retries happen faster. No need to wait 60s before retrying to connect -- at that point the user just refreshes the page anyway. So let's make this 2s, max.
mayagbarnes
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.
Was just manual testing ✅
Just couple lint things in the JS test run
Describe your changes
Today, when the Streamlit frontend is unable to connect to the server we eventually show an error dialog (after plenty of retries). But there are two issues:
The messaging in the error dialog is a bit cryptic.
→ This PR makes the message nicer to the user
While the error dialog is visible, we continue retrying to connect to the server. But if we're suddenly successful at establishing a connection to the sever, the "disconnected" dialog stays open.
→ This PR closes that dialog when reconnected.
PS: This PR also reduces the min and max time we use in our connection retry logic.
GitHub Issue Link (if applicable)
n/a
Testing Plan
Explanation of why no additional tests are neededE2E TestsAny manual testing needed?Contribution License Agreement
By submitting this pull request you agree that all contributions to this project are made under the Apache 2.0 license.