errors during web download aren't reported, hangs instead #65

New Issue

warner · 2007-06-10T04:12:50Z

warner commented

2007-06-10 04:12:50 +00:00

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.

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](wiki/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.

warner added the

labels 2007-06-10 04:12:50 +00:00

warner commented

2007-07-03 20:53:30 +00:00

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.

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](wiki/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.