securedrop-client icon indicating copy to clipboard operation
securedrop-client copied to clipboard

Client never gives up on files the Server cannot serve

Open cfm opened this issue 1 year ago • 1 comments

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

  1. Register as a source and submit something.
  2. Delete that source's directory from /var/lib/securedrop/store.
  3. 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.

cfm avatar Jul 12 '24 00:07 cfm

(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 avatar Jul 12 '24 00:07 cfm

@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?

eloquence avatar Jul 08 '25 00:07 eloquence

Noted in #2507.

eloquence avatar Jul 10 '25 18:07 eloquence

@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

cfm avatar Jul 11 '25 21:07 cfm