Investigate behaviour when files fail to download #1633
Comments
|
I was initally excited because @creviera pointed me to the timout logic in the client and reminded me that we may need to adjust that, and that the estimated timeout times could be why users report success downloading files in the Tails Journalist Interface, but not in the client. However, I've just done some very quick testing with files up to as large as 50MB, and aside from sync failures, where the server becomes fully unreachable (and it may be time to restart tor and hope for a better circuit), I have been well inside the download timeout window, even for 50MB files. I will look into this further next week, since files in the 10-50MB range should be very manageable for the client. We may also want to implement more sophisticated download/retry logic. |
|
Update: after looking more closely at relevant recent tor metrics, I do think we can alleviate some pain by adjusting the timeout length. I will put in a PR to do this. Ongoing, there are other improvements we could make (backoff strategy? better error reporting?) - I'm still going to investigate the issue of error notifications not being reported to see if I can repro. |
|
Hi, might I ask if the issue of error notifications is being investigated? I can't remember ever seeing "download failed" message and am still seeing a high proportion of large downloads showing as "downloading" without ever completing (even after hours - way beyond any likely timeout threshold). c.f. #1451 With no progress indicator or evidence that a download has stopped, and no option to cancel the current download attempt, the only action available to me is to assume that it has failed, and quit and relaunch the app to either reattempt to download or discover that the file has in fact downloaded after all. I should note that download via the old web-based Journalist interface is consistently more reliable - and, of course, using that I can see both progress and failure. So this is unlikely to be simply down to bad Tor connections on my side. |
|
Hi @hoyla - implementing progress and cancel options for downloads is still on our radar, and some sort of UX improvement is tentatively scoped for the next SDW release. But unfortunately, I'm not sure how quickly it will happen. We're a small crew these days and have recently been focusing on the upcoming SecureDrop server release, but hoping to put more time towards this and other workstation issues towards the end of the year. I'm sorry it's giving you grief. |
|
Since this is a ticket about investigating file download failure behaviour, I am including the following user reports.
|
|
Reproduction attempt. Client version 0.13.1. To reproduce, I uploaded an 11MB file though the source interface and then following each of the scenarios. Is there an easy server modification / test that triggers failure for one particular file? Scenario 1: shut down server
Scenario 2: disconnect from network on sys-net
Scenario 3: pause VM running serverThe result was the same as scenario 2. |
|
From the original description:
I'll have a PR for this shortly. |
DownloadDecryptionException is specially handled in Controller.on_file_download_failure(), so if we raise a different exception class, the download animation will never be stopped because file_missing is never emitted. It is worth a proper re-examination of our exception heirarchy and reducing the amount of indirection in the download flow, but that can be done outside of a hotfix. More debug logging is added to trace when slots are triggered. Refs #1633.
DownloadDecryptionException is specially handled in Controller.on_file_download_failure(), so if we raise a different exception class, the download animation will never be stopped because file_missing is never emitted. It is worth a proper re-examination of our exception heirarchy and reducing the amount of indirection in the download flow, but that can be done outside of a hotfix. More debug logging is added to trace when slots are triggered. Refs #1633.
There are multiple reasons this could fail and unfortunately the code has only gotten more complicated since we added partial retries to help mitigate this. I think we ultimately need better logging that admins can provide to use to give us indications of where the failures are coming from.
#2196 is kind of related, but doesn't actually address this case. I think our exception hierarchy is too complex and as a result, some exceptions slip through or are handled differently causing inconsistent UX. I think this is a good task for 0.16.0 |
DownloadDecryptionException is specially handled in Controller.on_file_download_failure(), so if we raise a different exception class, the download animation will never be stopped because file_missing is never emitted. It is worth a proper re-examination of our exception heirarchy and reducing the amount of indirection in the download flow, but that can be done outside of a hotfix. More debug logging is added to trace when slots are triggered. Refs #1633. (cherry picked from commit 3b183fb)
DownloadDecryptionException is specially handled in Controller.on_file_download_failure(), so if we raise a different exception class, the download animation will never be stopped because file_missing is never emitted. It is worth a proper re-examination of our exception heirarchy and reducing the amount of indirection in the download flow, but that can be done outside of a hotfix. More debug logging is added to trace when slots are triggered. Refs #1633. (cherry picked from commit 3b183fb)
Description
With stormy Tor weather, users may be experiencing more file download failures than usual, and there are some reports that the file download error is not appearing (file shows "Downloading" forever).
Filing to remind myself to investigate since this may be a regression.
Possibly Related: #1095
Other relevant issues in the "improve download experience" list:
The text was updated successfully, but these errors were encountered: