Opened at 2007-06-10T04:12:50Z
Closed at 2007-07-03T20:53:30Z
#65 closed defect (fixed)
errors during web download aren't reported, hangs instead
| Reported by: | warner | Owned by: | somebody |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.5.0 |
| Component: | code | Version: | 0.2.0 |
| Keywords: | Cc: | ||
| Launchpad Bug: |
Description
If an exception occurs during a download triggered by the web frontend, there's an Unhandled Errback written to the logs, but the web GET request itself never completes.
I think allmydata.download.Downloader should be changed to add an errback handler to the start() Deferred that will fire the DownloadTarget?'s fail() method. That would also mean that start() should never errback, which is kind of weird.. maybe the Failure should be sent to both fail() and the start() chain.
The webish code can use the fail() method to terminate the download GET with an error of some sort.
The easiest way to reproduce this is probably to corrupt a couple of files (the uri_extension block comes to mind) in all shares. The way I noticed it was to try to download a file that was uploaded with an earlier version.
Change History (1)
comment:1 Changed at 2007-07-03T20:53:30Z by warner
- Milestone set to 0.5.0
- Resolution set to fixed
- Status changed from new to closed
fixed, if the error occurs early enough then we return a 500 Internal Server Error and attach a traceback of the problem (most likely a NotEnoughPeersError?).
If the error occurs late (meaning after we've already started sending data), then our error-reporting options are much more limited. Fortunately most of the likely error situations will be detected before the first segment of data is validated and sent. This includes bogus URI, not enough peers holding data, and coding problems that lead to bad hashes everywhere. This does not include peers going away after the first segment is retrieved.