You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the Server has a submission or reply on record that it cannot serve (e.g., because it has been deleted from disk), the Client will keep trying to download it forever.
Steps to Reproduce
Register as a source and submit something.
Delete that source's directory from /var/lib/securedrop/store.
Log into the Client.
Expected Behavior
Sync eventually completes, modulo Tor weather.
Actual Behavior
Since the deleted source's disconnected submission can never be downloaded, sync never completes.
Comments
There's an obvious tension here between "fail when the Server cannot serve" and "keep trying when Tor weather is bad".
We should start by redesigning the overall Client—Server synchronization model. Consider this one problem that redesign will need to solve.
The text was updated successfully, but these errors were encountered:
(In fairness to the Client, the challenge here is for it to reach some form of consistency with, or at least a consistent representation of, a datastore that is inconsistent with itself....)
Description
When the Server has a submission or reply on record that it cannot serve (e.g., because it has been deleted from disk), the Client will keep trying to download it forever.
Steps to Reproduce
/var/lib/securedrop/store
.Expected Behavior
Sync eventually completes, modulo Tor weather.
Actual Behavior
Since the deleted source's disconnected submission can never be downloaded, sync never completes.
Comments
There's an obvious tension here between "fail when the Server cannot serve" and "keep trying when Tor weather is bad".
We should start by redesigning the overall Client—Server synchronization model. Consider this one problem that redesign will need to solve.
The text was updated successfully, but these errors were encountered: