Skip to content
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

after X continued failed metadata syncs, we need to raise an alert to the user #798

Closed
redshiftzero opened this issue Feb 11, 2020 · 3 comments · Fixed by #823
Closed

after X continued failed metadata syncs, we need to raise an alert to the user #798

redshiftzero opened this issue Feb 11, 2020 · 3 comments · Fixed by #823

Comments

@redshiftzero
Copy link
Contributor

On master there is a bug where after any failed metadata sync (this will be fixed with securedrop-sdk 0.0.13 as the issue was in the SDK logic) we raise the login window. Once that's resolved, the behavior we will have is the following:

  1. Metadata sync fails transparently to the user and gets retried. We now go to either 2a or 2b.

2a. Metadata sync then succeeds, all is well.

2b. Metadata sync continues to fail. User will only get the retry / paused behavior if the user then tries to take an action using the two main queues.

We need to limit the number of times (or the amount of time) that a metadata sync can fail in a transparent manner such that the user gets the retry window when they likely do need to take action: plug back in their network cable or whatever has gone wrong with their network connection.

Suggestion: modify the number of retries here https://github.com/freedomofpress/securedrop-client/blob/master/securedrop_client/sync.py#L118 and modify the failure signal behavior in the case of RequestTimeoutError

@sssoleileraaa
Copy link
Contributor

On master there is a bug where after any failed metadata sync (this will be fixed with securedrop-sdk 0.0.13 as the issue was in the SDK logic) we raise the login window

Just want to note that once the client uses the latest SDK with the fix, this code in the client on master will just work (nothing needs to change here):

def on_sync_failure(self, result: Exception) -> None:
"""
Called when syncronisation of data via the API fails after a background sync. If the reason
a sync fails is ApiInaccessibleError then we need to log the user out for security reasons
and show them the login window in order to get a new token.
"""
logger.debug('The SecureDrop server cannot be reached due to Error: {}'.format(result))
if isinstance(result, ApiInaccessibleError):
self.invalidate_token()
self.logout()
self.gui.show_login(error=_('Your session expired. Please log in again.'))

@sssoleileraaa
Copy link
Contributor

(in the client we only ask the user to reauthenticate when we see an ApiInaccessibleError)

@sssoleileraaa
Copy link
Contributor

2b. Metadata sync continues to fail. User will only get the retry / paused behavior if the user then tries to take an action using the two main queues.

True, the metadata sync background thread silently "pings" the server every 15 seconds

We need to limit the number of times (or the amount of time) that a metadata sync can fail in a transparent manner such that the user gets the retry window when they likely do need to take action: plug back in their network cable or whatever has gone wrong with their network connection.

Agreed, and it would be useful to determine whether or not we're seeing repeated ConnectTimeout errors vs ReadTimeout errors, because one means we can't connect to the server at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants