canvas-lms icon indicating copy to clipboard operation
canvas-lms copied to clipboard

File Uploads cannot complete over slow or throttled connection

Open srphillips opened this issue 6 years ago • 1 comments

Summary:

Canvas experiences issues when uploading somewhat larger files over slower connections. It didn't seem to be tied to a specific file type or size that I could see, but I tested with the files that we were seeing it happen with to reproduce the issue consistently. The key seemed to be a file that took a significant time to upload over the connection speed given the file size. Tested in Firefox 65.0 and Google Chrome 73.0.3683.75 in the following environments:

  • Local Development (Using the Wiki Quick Start Guide)
  • Self-hosted Production deployment on a cloud service provider, using the Local Disk Storage option not AWS S3 or equivalent service
  • Instructure hosted enviroment

Tests were done in each browser with any add-ons enabled and in a private browser window with no add-ons enabled at all. I've seen this happen with a number of different types of files, but the most common were somewhat larger files, usually zip or video files. The files I used to reproduce this issue were ~70MB zip files and ~120MB mp4 files that we had on hand. A publicly available file that I used for testing this was the Ubuntu Server LTS Netboot mini.iso placed in a zip file (comes to around 70MB).

Steps to reproduce:

  1. Open browser to an instance of Canvas
  2. Login and navigate to "Files" section of a Course where you have permissions to upload files
  3. Throttle speed of connection to simulate a slow network speed -- I used Firefox's built-in throttling and selected "Wi-Fi" and the same feature in Google Chrome
  4. Begin the file upload process by clicking the "Upload" button at the upper right of the Files page
  5. Select a file to upload that will take some time over the throttled connection -- If prompted to choose whether or not to "Extract" or "Upload" the zip file, choose "Upload"
  6. Wait sufficient time for file to upload

Expected behavior:

Expect the file to upload successfully and be available to access in Canvas.

Actual behavior:

Local Development Environment:

  • After sufficient time (up to an hour after file should've finished uploading), the GUI either hangs entirely or gives an error status saying "Error: Unable to transmit the file to the storage service. The Service may be down or you may need to re-login to Canvas." Either way, the file is doesn't ever successfully upload.

Self-Hosted Production Environment

  • After waiting sufficient time (tested waiting up to an hour after file should've finished uploading), the GUI displays an error from the browser for a 504 Gateway Timeout.
  • Canvas production server logs indicate that a 400 Bad Request was thrown at some point during the upload process, but never actually returned that response to the browser, at which point, our load balancers timed out the connection after a lengthy period of inactivity.

Instructure Hosted Environment

  • File upload does usually end up displaying an empty or partially filled progress bar, but hangs without change for long after the file should be uploaded (waited over 3 hours for this one). The GUI displayed an error once saying that an error had occurred, but without any additional information.

Additional notes:

Attempting to upload test files without any network throttling succeeded multiple times in each environment. It should be noted that in each case, the first POST to the files api to get a token to upload the file seemed to succeed and return what was necessary for the subsequent API call, but the second never succeeded. It's almost like the parameters never made it to the second API POST call to the files_api endpoint.

srphillips avatar Mar 26 '19 16:03 srphillips

Thanks for contributing to this issue. As it has been 2 years since the last activity, we are automatically closing the issue in 30 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or post a message on the mailing list. We'll gladly take a look again!

stale[bot] avatar Jan 09 '22 10:01 stale[bot]