5

Ref: https://github.com/balderdashy/skipper/issues/49

Adapter: skipper-gridfs

Basic controller code:

req.file('fileTest')
        .upload({

        // You can apply a file upload limit (in bytes)
        maxBytes: maxUpload,
        adapter: require('skipper-gridfs'),
        uri: bucketConnect,
        saveAs : function (__newFileStream,cb) {
            cb(null, __newFileStream.filename);
        }

    }, function whenDone(err, uploadedFiles) {
        if (err) {
            var error = {  "status": 500, "error" : err };
            return res.serverError(error);
        }else {

I have a jQuery-File-Upload client ( https://blueimp.github.io/jQuery-File-Upload/ ) impementing the "cancel" procedure by using jqXHR abort described here (https://github.com/blueimp/jQuery-File-Upload/wiki/API ):

$('button.cancel').click(function (e) {
    jqXHR.abort();
});

After the client aborts, the server crashes with the following message:

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: Request aborted
    at IncomingMessage.onReqAborted (.../node_modules/sails/node_modules/skipper/node_modules/multiparty/index.js:175:17)
    at IncomingMessage.EventEmitter.emit (events.js:92:17)
    at abortIncoming (http.js:1911:11)
    at Socket.serverSocketCloseListener (http.js:1923:5)
    at Socket.EventEmitter.emit (events.js:117:20)
    at TCP.close (net.js:466:12)

I've used try/catch but it didn't work, the server crashes anyway.

I am not sure if this is a Skipper issue or a Multiparty issue -- my knowledge stops here ( https://github.com/andrewrk/node-multiparty/blob/master/index.js ):

function onReqAborted() {
    waitend = false;
    self.emit('aborted');
    handleError(new Error("Request aborted"));
  }

  function onReqEnd() {
    waitend = false;
  }

  function handleError(err) {
    var first = !self.error;
    if (first) {
      self.error = err;
      req.removeListener('aborted', onReqAborted);
      req.removeListener('end', onReqEnd);
      if (self.destStream) {
        self.destStream.emit('error', err);
      }
    }

    cleanupOpenFiles(self);

    if (first) {
      self.emit('error', err);
    }
  }

At first I thought this was the way the jqXHR request was aborted, but it seems to be a generic Skipper issue on aborted uploads, since the simple act of closing the tab during an upload will crash the server (different message):

_stream_writable.js:233
    cb(er);
    ^
TypeError: object is not a function
    at onwriteError (_stream_writable.js:233:5)
    at onwrite (_stream_writable.js:253:5)
    at WritableState.onwrite (_stream_writable.js:97:5)
    at Writable.<anonymous> (.../node_modules/skipper-gridfs/index.js:179:25)
    at Writable.g (events.js:180:16)
    at Writable.EventEmitter.emit (events.js:117:20)
    at PassThrough.<anonymous> (.../node_modules/skipper-gridfs/index.js:194:36)
    at PassThrough.g (events.js:180:16)
    at PassThrough.EventEmitter.emit (events.js:117:20)
    at .../node_modules/sails/node_modules/skipper/standalone/Upstream/prototype.fatalIncomingError.js:55:17

I have tried aborting the upload by closing the tab while using a simple upload controller (not Skipper) and there is no crash:

var uploadFile = req.file('fileTest');
    console.log(uploadFile);

    uploadFile.upload(function onUploadComplete (err, files) {                // Files will be uploaded to .tmp/uploads

        if (err) return res.serverError(err);                              // IF ERROR Return and send 500 error with error

        console.log(files);
        res.json({status:200,file:files});
    });

So, did anybody see this happening and is there any workaround?

noderman
  • 1,934
  • 1
  • 20
  • 36
  • I have the same problems. Apperently, it has to do with the Skipper disk file adapter (https://github.com/balderdashy/skipper-disk/pull/6). So a workaround might be to use another adapter. You can also use this temporary solution: https://github.com/balderdashy/skipper/issues/36#issuecomment-53732951 – Lutsen Dec 18 '14 at 10:06
  • I'm no sure: to me this issue happens only when I use the GridFS adapter. When using skipper-disk, you can cut the upload without crashing the server. I haven't tried skipper-S3 yet because I am not familiar with the use of AWS buckets, but this is on my list. – noderman Dec 20 '14 at 00:31
  • Finaly, I found out my problems had to do with Angular instead of Sails. Angular will serialize the data to upload, which will crash Sails. The solution to my Angular problem is explained here: http://uncorkedstudios.com/blog/multipartformdata-file-upload-with-angularjs – Lutsen Jan 05 '15 at 13:51
  • Thanks Lutsen. If Sails can be brought down with a client request, this is a critical issue. I have raised this on their Github issues page, but I see no activity. – noderman Jan 06 '15 at 15:37

2 Answers2

1

This issue has been solved in skipper@0.5.4 and skipper-disk@0.5.4

Ref.: https://github.com/balderdashy/skipper/issues/49

noderman
  • 1,934
  • 1
  • 20
  • 36
  • 2
    Hi @mikermcneil, actually this seems to still be a problem. I am working around this with `domains` according to a suggestion on issue #49. Otherwise, Sails will still crash :-( – noderman Jan 21 '16 at 01:30
  • 1
    Just reopened the issue and will take a look asap- thanks for letting me know! – mikermcneil Jan 25 '16 at 00:51
1

Also there is an Issue in skipper-gridfs@0.5.3

Link: https://github.com/willhuang85/skipper-gridfs/issues/20

1nstinct
  • 1,745
  • 1
  • 26
  • 30
  • This is actually the last error thrown by the upload cycle. Two errors are thrown after the first error is caught by the callback in `.upload`. https://github.com/balderdashy/skipper/issues/49#issuecomment-196421841 – noderman Mar 15 '16 at 14:30