-
Notifications
You must be signed in to change notification settings - Fork 42
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
health checker - auto resume #491
Comments
When the queue is paused, the message "The SecureDrop server cannot be reached." with retry link appears in the error status bar. This error message currently doesn't go away until the user clicks "retry." Once the health checker is added with auto-resume, this message should be able to automatically go away without the user action. |
For the health checker we could add a new class (similar to the metadata sync running on a timer) that does not have an API token (in the interest of keeping authenticated API calls all being triggered through a single location that is the queue). We could add an SDK endpoint to hit the unauthenticated endpoint here - alternatively, a better thing to do would be to implement freedomofpress/securedrop#4698 as an unauthenticated endpoint since we need it anyway for the client, and then add an SDK method for that. We're never really going to be able to distinguish 1. general network connectivity issue from 2. admin has just cycled the HidServAuth credentials, so to that end if things keep failing there should probably just be a “Talk to your securedrop administrator” message. |
Upon consideration, this seems like a nice-to-have feature for the beta, but not a must-have. Hopefully, once all actions are handled by the queue, errors should be rare since we do retries automatically a limited number of times. If the main reason to do this is to have the Retry dialog disappear magically when connectivity is restored, I would vote to defer to Post-Beta. Thoughts @creviera @redshiftzero ? |
I agree with this |
(Added to Post-Beta for now.) |
(Adjusted milestones again as this is being handled within #612) |
closed by #612 |
Acceptance Criteria
Given that some operations have repeatedly failed due to network issues
When I do nothing
Then the client should periodically test connectivity
And the error message should disappear when connectivity is restored
And the queue should be resumed when connectivity is restored
The text was updated successfully, but these errors were encountered: