#951 assigned defect

uploads aren't cancelled by closing the web page

Reported by: zooko Owned by: zooko
Priority: major Milestone: undecided
Component: code-frontend-web Version: 1.6.0
Keywords: usability upload large wui ophandle Cc: zooko
Launchpad Bug:


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).

Change History (11)

comment:1 Changed at 2010-02-15T00:01:46Z by davidsarah

  • Keywords wui ophandle added
  • Milestone changed from undecided to eventually

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.

comment:2 Changed at 2010-02-27T08:55:03Z by davidsarah

  • Milestone changed from eventually to 1.7.0

comment:3 Changed at 2010-05-16T05:58:44Z by zooko

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).

comment:4 Changed at 2010-05-16T05:58:59Z by zooko

  • Milestone changed from 1.7.0 to 1.8.0
  • Owner set to zooko
  • Status changed from new to assigned

comment:5 Changed at 2010-07-24T05:38:57Z by zooko

  • Milestone changed from 1.8.0 to eventually

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

comment:6 Changed at 2012-01-26T23:42:45Z by warner

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.

comment:7 Changed at 2012-01-26T23:58:11Z by warner

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)

comment:8 Changed at 2012-01-27T00:15:37Z by warner

.. 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)

comment:9 Changed at 2012-01-27T01:08:42Z by davidsarah

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:6 works as intended.

comment:10 Changed at 2012-01-27T02:09:21Z by davidsarah

  • Milestone changed from eventually to undecided

comment:11 Changed at 2012-01-27T03:23:39Z by zooko

  • Cc zooko added
Note: See TracTickets for help on using tickets.