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

Make sync continuous #739

Merged
merged 10 commits into from Feb 6, 2020
Merged

Make sync continuous #739

merged 10 commits into from Feb 6, 2020

Conversation

sssoleileraaa
Copy link
Contributor

@sssoleileraaa sssoleileraaa commented Jan 28, 2020

Description

Followup from #652
Fixes #672
Fixes #671

This is the last PR for the sync architecture change to have a continuous metadata syncs that occur frequently and unpause the queue when they succeed

This is dependent on the following PRs getting merged first (for now I cherry-picked them here so others working on the client will have visibility):

This PR includes the following changes:

  • removing the metadata queue in favor of a background thread that doesn't pause when other queues are paused
  • removing the last sync_api call on login and removing sync_api all together

Test Plan

  1. See that the GUI still shows the active sync animation in the top left of the client
  2. Force the queues to pause and see how our background sync thread will continue to run syncs until one succeeds and unpauses the queues

@sssoleileraaa
Copy link
Contributor Author

This cannot be merged until #732 is merged, which removes user-initiated syncs via the Refresh button in the upper left-hand corner of the client.

@@ -334,7 +337,7 @@ def on_authenticate_success(self, result):
self.gui.show_main_window(user)
self.update_sources()
self.api_job_queue.login(self.api)
self.sync_api()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is where we used to call sync_api on login which i replaced with starting the background sync thread

@@ -344,6 +347,7 @@ def on_authenticate_failure(self, result: Exception) -> None:
error = _('There was a problem signing in. '
'Please verify your credentials and try again.')
self.gui.show_login_error(error=error)
self.api_sync.stop()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when we log out we need to make sure the background sync thread does not continue making api requests to get new data from the server

@sssoleileraaa
Copy link
Contributor Author

sssoleileraaa commented Jan 28, 2020

I left some inline comments to help with review. This is ready. Update: Actually it makes sense that this should be blocked until the current sync_api removal prs are merged.

@sssoleileraaa
Copy link
Contributor Author

This is ready for review. The last PR dependency this relies on is this one: #737 (removal of sync_api from the gui and controller when file is missing).

For now you can cherry-pick the 2 commits from that PR to here to see tests pass and review the code.

@sssoleileraaa sssoleileraaa moved this from In Development to Ready for Review in SecureDrop Team Board Jan 30, 2020
@sssoleileraaa sssoleileraaa force-pushed the make-sync-continuous branch 2 times, most recently from 560a53d to 11c09c6 Compare January 31, 2020 21:33
@sssoleileraaa
Copy link
Contributor Author

This is no longer blocked

@sssoleileraaa
Copy link
Contributor Author

rebased on master branch and resolved conflicts with all the great changes coming in

@redshiftzero redshiftzero moved this from Ready for Review to Under Review in SecureDrop Team Board Feb 4, 2020
@redshiftzero
Copy link
Contributor

I started looking at this today - this is looking pretty good to me but I'll finish review tomorrow AM and drop any comments in the PR for when you sign on @creviera

securedrop_client/sync.py Outdated Show resolved Hide resolved
securedrop_client/sync.py Outdated Show resolved Hide resolved
@sssoleileraaa
Copy link
Contributor Author

review comments addressed

@sssoleileraaa
Copy link
Contributor Author

rebased on master branch and signed commits

@redshiftzero
Copy link
Contributor

excellent, my comments above were addressed, thanks! so there's an unexpected behavior that I observed when I was running this in Qubes: when I paused my app-staging VM in order to test the pause behavior, I got the login screen and a "session expired, login again" [paraphrasing] message - have you seen this too? My expectation was that I'd see a pause and the retry banner... I'm not sure if it's related to this change yet

@sssoleileraaa
Copy link
Contributor Author

sssoleileraaa commented Feb 6, 2020

when I paused my app-staging VM in order to test "session expired, login again" [paraphrasing] message - have you seen this too?

I have not seen this but I'll work on repro'ing. This would mean that the MetadataSyncJob is seeing an ApiInaccessibleError when this occurs, so I'll pay close attention to the logs, and will also check master. I believe we're correctly interpreting AuthError to mean the token is invalid/expired, so my guess is that the local api_client is getting set to None somewhere when it shouldn't be.

Update:

We are correctly interpreting AuthError to mean the token is invalid/expired but the SDK is incorrectly sending request timeout and other types of errors as AuthErrors. See comment below for explanation.

@sssoleileraaa
Copy link
Contributor Author

It looks like this is occurring because of this issue I just opened up in the SDK repo: freedomofpress/securedrop-sdk#109

The reason this has gone unnoticed on master is because we don't ask the user to provide credentials when we see an ApiInaccessibleError. Instead we just pause the queue the way we pause the queue for request timeouts as well.

Once the client begins receiving RequestTimeoutError instead of an AuthError this will work. I also wrote up in that sdk issue that it would be valuable to be able to receive a new ConnectTimeout error to indicate that we can't reach the server as opposed to a request timeout or read timeout.

@kushaldas
Copy link
Contributor

While running the branch, I am getting the following error in the log:

2020-02-06 15:46:12,722 - securedrop_client.queue:145(process) ERROR: Skipping job
2020-02-06 15:46:12,803 - securedrop_client.api_jobs.downloads:149(_download) INFO: File downloaded to /tmp/tmp.lkSEe1s2av/data/colorless_throes/1-colorless_throes-msg.txt
2020-02-06 15:46:12,910 - securedrop_client.api_jobs.downloads:168(_decrypt) INFO: File decrypted: 1-colorless_throes-msg.txt (decrypted file: )
2020-02-06 15:46:12,912 - securedrop_client.queue:144(process) ERROR: Job <securedrop_client.queue.RunnableQueue object at 0x7fdca48094c8> raised an exception: AttributeError: 'RunnableQueue' object has no attribute 'pinged'
2020-02-06 15:46:12,913 - securedrop_client.queue:145(process) ERROR: Skipping job
2020-02-06 15:46:13,019 - securedrop_client.api_jobs.downloads:149(_download) INFO: File downloaded to /tmp/tmp.lkSEe1s2av/data/colorless_throes/2-colorless_throes-msg.txt
2020-02-06 15:46:13,177 - securedrop_client.api_jobs.downloads:168(_decrypt) INFO: File decrypted: 2-colorless_throes-msg.txt (decrypted file: )
2020-02-06 15:46:13,179 - securedrop_client.queue:144(process) ERROR: Job <securedrop_client.queue.RunnableQueue object at 0x7fdca48094c8> raised an exception: AttributeError: 'RunnableQueue' object has no attribute 'pinged'
2020-02-06 15:46:13,179 - securedrop_client.queue:145(process) ERROR: Skipping job
2020-02-06 15:46:13,286 - securedrop_client.api_jobs.downloads:149(_download) INFO: File downloaded to /tmp/tmp.lkSEe1s2av/data/prepositional_technicolor/1-prepositional_technicolor-msg.txt

@sssoleileraaa
Copy link
Contributor Author

ah looks like a pinged signal was missed in the removal

Copy link
Contributor

@redshiftzero redshiftzero left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all my comments were addressed, and kushal's comment was addressed in the latest change so I'm gonna approve this 🚢

@redshiftzero
Copy link
Contributor

there is still the outstanding issue discovered during review here, but that will be resolved separately as part of freedomofpress/securedrop-sdk#109

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging this pull request may close these issues.

metadata syncs are not continuous Trigger sync without calling sync_api after login
4 participants