Meteor-files: S3 + createThumbnails: after upload interceptDownload returns false until refreshing the page

Created on 18 Aug 2016 · 3Comments · Source: veliovgroup/Meteor-Files

Hello and thank you for this fantastic package. I feel like I have control of my uploads with Meteor for the first time :)

I am using AWS S3 following the docs in combination with the createThumbnails example from the demo.

It is working beautifully except that only the original file is available initially. Requiring a page refresh or in a hard to explain case: only after opening a new browser window.

I am displaying the media immediately via a fineOne() and image.link("thumbnail").

The data is reactively updating as createThumbnails processes the images and the versions.thumbnail.meta.pipeFrom field contains my cloudfront URL.

I noticed that the interceptDownload callback returns false because it is called before the sendToStorage function is called from onAfterUpload; and it is only called once.

Edit: I also have noticed now that sometimes on subsequent refreshes the interceptDownload callback returns true -- but the image asset is still returned at original size.

Perhaps this boils down to a browser cache issue... (I am using Chrome)

Workaround: I ended up checking for the existence of versions.thumbnail.meta.pipeFrom before calling generating a link and that solved my issue since the original image never gets loaded into the browser!

Thanks again.

question

Source

owenhoskins

Most helpful comment

Yes, it fulfilled my questions and more, thank you for the detailed breakdown! Till later. best, O

owenhoskins on 24 Aug 2016

🎉1 👍1

All 3 comments

Hi @owenhoskins

Hello and thank you for this fantastic package. I feel like I have control of my uploads with Meteor for the first time :)

Thank you, for using this package. I'm glad to hear it, means a lot to me :)

It is working beautifully except that only the original file is available initially. Requiring a page refresh or in a hard to explain case: only after opening a new browser window.

This was made to avoid any UX loss, as thumb or any other subversion may be unavailable, the _MF_ package will reply with original file. It has both pros and cons, currently we believe it's better to reply with something then not reply at all.

The data is reactively updating as createThumbnails processes the images and the versions.thumbnail.meta.pipeFrom field contains my cloudfront URL.

I'd better wait for versions.thumbnail. This is how it works on demo app: we wait for versions.thumbnail40

I noticed that the interceptDownload callback returns false because it is called before the sendToStorage function is called from onAfterUpload; and it is only called once.

Expected behaviour, as sendToStorage and all other code in onAfterUpload is asynchronous. You have a two options wait for data on client (_see above_). Or make in synchronous via Fibers/Future. I'm personally prefer to wait for data to update.

onAfterUpload does not blocks file serving, it's a signal what file is uploaded, next you can do whatever you need with it. But if someone will request a file between onAfterUpload and sendToStorage, interceptDownload will work with default behaviour. Sounds complex... I hope you got the idea.