KSP-SpaceDock/SpaceDock

Uploads may be timing out and not displaying the error

Closed this issue · 4 comments

Problems

@zorg2044 reported on the SpaceDock Discord that the upload of BDB (~660 MB) was failing. The error message was non-specific:

image

We created an error handler that's supposed to set that text to whatever message we receive from Dropzone, but the above is the default text from update.html intended for when required fields are blank.

Causes

I did some cursory code auditing and found two suspicious things:

  1. Dropzone may have a 30-second timeout per chunk in the release we're using. More recent releases have no timeout by default (but can have one configured).
  2. In its own code, Dropzone treats its error function's message parameter as either a string or as an object with a string .error property:
      // Called whenever an error occurs
      // Receives `file` and `message`
      error(file, message) {
        if (file.previewElement) {
          file.previewElement.classList.add("dz-error");
          if (typeof message !== "string" && message.error) {
            message = message.error;
          }
          for (let node of file.previewElement.querySelectorAll(
            "[data-dz-errormessage]"
          )) {
            node.textContent = message;
          }
        }
      },
    But SpaceDock accesses the .reason property instead:
    error: (file, errorMessage, xhr) ->
    alert = $("#error-alert")
    alert.text(errorMessage.reason)
    alert.removeClass('hidden')

    error: (file, errorMessage, xhr) ->
    alert = $("#error-alert")
    alert.text(errorMessage.reason)
    alert.removeClass('hidden')

    This may be why the error message didn't appear at timeout.

Suggestions

  1. Update to the latest Dropzone to remove the timeout
  2. Update the error handlers to check whether errorMessage is a string and whether it has a .error property in addition to .reason
    But mainly we should test out what the errorMessage parameter actually looks like. I can't right now because I'm in Windows, but it would be easy to set a really short timeout and put a breakpoint in the error handler.

Testing locally with a 10ms timeout, it looks like the sequence of events is different than it initially sounded. I assumed the error appeared spontaneously during the upload (thus implicating the error handler that we create), but it looks like it's actually a response to clicking the "Create Your Mod" button (I'm testing on the create page because the code is the same and it's easier to create a new mod from scratch in a local testing server).

Breakpoints in error and success are never hit. So the upload fails but we get no notification of that? Yet somehow we still raise the error...

error is called based on some console.log debugging, it's just that the breakpoint doesn't work. Probably because it's a lambda, sigh.

        console.log JSON.stringify(errorMessage)
"Request timedout after 10 seconds"

So errorMessage is indeed just a string. Also Dropzone's error message incorrectly describes milliseconds as seconds (fixed in dropzone/dropzone@4fe0f6b).

Ahh right, the upload happens when you click the submit button, not when the file appears in the Dropzone control. That's why it happens when it does.

It's somewhat likely that these weren't timing out but rather failing due to the full-disk problem that was fixed today. It still makes sense to fix the code, though.