uploads aren't cancelled by closing the web page #951

New Issue

zooko · 2010-02-14T20:05:44Z

zooko commented

2010-02-14 20:05:44 +00:00

As described in #950 (upload doesn't appear in the Recent Uploads Downloads page), I started a large upload and then closed the tab. Later I discovered that the upload was still running (by using flogtool tail on the gateway).

As described in #950 (upload doesn't appear in the Recent Uploads Downloads page), I started a large upload and then closed the tab. Later I discovered that the upload was still running (by using `flogtool tail` on the gateway).

zooko added the

labels 2010-02-14 20:05:44 +00:00

zooko added this to the undecided milestone 2010-02-14 20:05:44 +00:00

davidsarah commented

2010-02-15 00:01:46 +00:00

This could be implemented using an onbeforeunload handler. That should catch navigating away from the upload tab by any method, as well as closing it (see http://www.4guysfromrolla.com/demos/OnBeforeUnloadDemo1.htm for a demo).

The upload operation would need to return an ophandle so that it can be referenced by a cancel operation.

This could be implemented using an `onbeforeunload` handler. That should catch navigating away from the upload tab by any method, as well as closing it (see <http://www.4guysfromrolla.com/demos/OnBeforeUnloadDemo1.htm> for a demo). The upload operation would need to return an ophandle so that it can be referenced by a cancel operation.

tahoe-lafs modified the milestone from undecided to eventually

2010-02-15 00:01:46 +00:00

tahoe-lafs modified the milestone from eventually to 1.7.0

2010-02-27 08:55:03 +00:00

zooko commented

2010-05-16 05:58:44 +00:00

This is related to #1032 (Display active HTTP upload operations on the status page), #952 (multiple simultaneous uploads of the same file) and #320 (add streaming (on-line) upload to HTTP interface).

zooko modified the milestone from 1.7.0 to 1.8.0

2010-05-16 05:58:59 +00:00

zooko self-assigned this 2010-05-16 05:58:59 +00:00

zooko commented

2010-07-24 05:38:57 +00:00

It was impulsive of me to put this ticket into the 1.8 Milestone. We have enough other important issues in front of us.

zooko modified the milestone from 1.8.0 to eventually

2010-07-24 05:38:57 +00:00

warner commented

2012-01-26 23:42:45 +00:00

Hm, I don't know which case this is about:

if the browser drops the TCP connection before the HTTP body has made it to the gateway, that should clearly stop doing work as soon as the connectionLost is received. There should not be an error in the logs, although it'd be ok if we emitted a one-line warning (perhaps log.UNUSUAL, but not log.WEIRD)
if the browser successfully gets the HTTP body to the gateway, but then disconnects while the gateway-to-server upload is still running: hm, good question. I'm inclined to think we should process the upload to completion, even though there's no longer a channel to deliver the filecap to the user. This would let their next attempt short-circuit (shares are already present on the grid) and finish faster.

Hm, I don't know which case this is about: * if the browser drops the TCP connection before the HTTP body has made it to the gateway, that should clearly stop doing work as soon as the connectionLost is received. There should not be an error in the logs, although it'd be ok if we emitted a one-line warning (perhaps log.UNUSUAL, but not log.WEIRD) * if the browser successfully gets the HTTP body to the gateway, but then disconnects while the gateway-to-server upload is still running: hm, good question. I'm inclined to think we should process the upload to completion, even though there's no longer a channel to deliver the filecap to the user. This would let their next attempt short-circuit (shares are already present on the grid) and finish faster.

warner commented

2012-01-26 23:58:11 +00:00

Zooko explained to me on IRC (and in #950) that it's the second case. I think it'd be a bit gratuitous to terminate the upload just because they disconnected, but it's predictable and understandable, so I can go along with it.

This probably needs a request.notifyFinish(cb) on the web side, and a bunch of new .cancel code on the Uploader side. Our current interface just returns a Deferred, and doesn't have any sort of "upload-in-progress" handle. Maybe the new "cancellable Deferred" code in recent Twisteds could simplify this? like:

d = do_upload(body)
request.notifyFinish(d.cancel)

Zooko explained to me on IRC (and in #950) that it's the second case. I think it'd be a bit gratuitous to terminate the upload just because they disconnected, but it's predictable and understandable, so I can go along with it. This probably needs a `request.notifyFinish(cb)` on the web side, and a bunch of new `.cancel` code on the Uploader side. Our current interface just returns a Deferred, and doesn't have any sort of "upload-in-progress" handle. Maybe the new "cancellable Deferred" code in recent Twisteds could simplify this? like: ``` d = do_upload(body) request.notifyFinish(d.cancel) ```

warner commented

2012-01-27 00:15:37 +00:00

.. and d.cancel() appeared in Twisted-10.1, which just so happens to be the version we're already requiring (for FTP async close). So the trick will be in adding cancel functionality to the Uploader (probably a flag that gets checked after each segment, just like for the downloader), and use finish_d = Deferred(cancel=self.setCancelFlag)

.. and d.cancel() appeared in Twisted-10.1, which just so happens to be the version we're already requiring (for FTP async close). So the trick will be in adding cancel functionality to the Uploader (probably a flag that gets checked after each segment, just like for the downloader), and use `finish_d = Deferred(cancel=self.setCancelFlag)`

davidsarah commented

2012-01-27 01:08:42 +00:00

If the file upload is to a mutable file, then the client already has the cap, and so the operation should complete in the second case. (The client has successfully submitted the new contents. Not sticking around to confirm that the publish succeeded is careless, but arguably not incorrect.)

So, do we want mutable and immutable file uploads to behave differently? I would say not, and therefore I would suggest closing this as wontfix, assuming the first case in comment:75449 works as intended.

If the file upload is to a mutable file, then the client already has the cap, and so the operation should complete in the second case. (The client has successfully submitted the new contents. Not sticking around to confirm that the publish succeeded is careless, but arguably not incorrect.) So, do we want mutable and immutable file uploads to behave differently? I would say not, and therefore I would suggest closing this as wontfix, assuming the first case in [comment:75449](/tahoe-lafs/trac-2024-07-25/issues/951#issuecomment-75449) works as intended.

tahoe-lafs modified the milestone from eventually to undecided

2012-01-27 02:09:21 +00:00

Sign in to join this conversation.