Client never gives up on files the Server cannot serve
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
- 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.
(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....)
@cfm With the v2 sync work underway, I would suggest we close this out, but capture the desired behavior in #2507 - what do you think?
Noted in #2507.
@eloquence, I did consider this in https://github.com/freedomofpress/securedrop-client/issues/2507#issuecomment-3059281928, but I came to the conclusion that the concrete requirement belongs to #2417:
- give up in pathological cases (e.g., #2112), but perhaps allow retrying manually