Improve upload error handling

[mzur]

Improve the upload error handling as follows: If there is an error for an uploaded file, show a popup displaying the error (and the filename). The popup should offer an option to cancel the upload or to skip this file and continue with the remaining files.

[mzur]

In addition: If there is an error with an uploaded file, retry the upload after 5 s (?). If this also fails, show the error. This can be helpful if the BIIGLE instance is updated during an upload und unavailable for a few seconds.

[mzur]

@lehecht Can you please have a look at this sometime? I see quite a few errors where file uploads abort because the object storage temporarily doesn't work. A simple retry and better error handling would be nice. The retry should also be done for chunked large files.

[lehecht]

In addition: If there is an error with an uploaded file, retry the upload after 5 s (?).

There is already a mechanism to retry the image upload. Should I replace this with your idea or maybe just increase the number of retries?
Currently RETRY_UPLOAD = 2 is used.

[mzur]

This issue is about the client-side upload. It works like this:

Client -> Server -> Storage

The retry you linked is from Server to Storage. This issue is about a retry and better error handling from Client to Server. Maybe it has a retry mechanism, too (I don't remember and didn't look), but the "skip or cancel" popup should also be added.

[mzur]

On second thought, a popup immediately after the error might not be the ideal solution. I imagine sometimes people just let large volumes of data upload unsupervised (e.g. over night). Then they come back in the morning and see an error after the first file and the popup, so the rest of the files were not uploaded. A better way would be to automatically skip files with errors and then at the end (when all files without errors were uploaded) show a popup asking to retry or skip the failed files.

[lehecht]

The retry you linked is from Server to Storage. This issue is about a retry and better error handling from Client to Server. Maybe it has a retry mechanism, too (I don't remember and didn't look), but the "skip or cancel" popup should also be added.

What I meant was, if I should replace the number of retries by the 'retry after 5 s'-idea (on the client side).

[mzur]

Is there a retry mechanism on the client side then? The Server to Storage retry mechanism should not be changed. The client side retry mechanism can have the 5 s delay.

[lehecht]

Is there a retry mechanism on the client side then?

Yes, there it uses also 2 retries.

[lehecht]

The client side retry mechanism can have the 5 s delay

So should I replace the former mechanism or add this delay?

[mzur]

I see, thanks. Please add the delay to the existing mechanism and increase the number of retries to 3. Then add the mechanism of first skipping failed uploads and finally asking to retry or skip all failed files described above. You can create two separate PRs for this, so the first change is published more quickly.

[lehecht]

@mzur

[...] show a popup asking to retry or skip the failed files.

What do you think about this alternative to a popup? I saw something similar for already initialized files that were not uploaded.
But if you still prefer a popup, I'll use one.

[mzur]

I like your idea! Some additional thoughts:

• Maybe the failed files can also be highlighted with text-warning
• The "Add directory, ..., Submit" buttons should disappear as they no longer make sense in this context
• The "Re-upload, ..." buttons can have normal size
• The "Re-upload" button can have btn-success as this is the recommended option
• The whole message with buttons could be displayed inside a:

  <div class="panel panel-warning">
     <div class="panel-body text-warning>
     </div>
  </div>
  

  This is the box that BIIGLE also uses elsewhere.
• Alternative button labels could be "retry failed files" and "skip failed files" to make the actions very clear.

[lehecht]

@mzur

Maybe the failed files can also be highlighted with text-warning

Should I extend the fileBrowser component and its used components or apply the changes directly in these core files?

[mzur]

It's probably easier to update the core files, right? You can add a new optional property warningFiles or some such as an array of files that should be highlighted. If the prop is not given, the file browser behaves as before.

[lehecht]

@mzur

How should I handle failed files with very long file names? It could happen, that the "failed" info is not (completly) visible anymore because of the box size.

[mzur]

I suggest that you just change the color of the whole filename. Instead of showing "failed", you could replace the file icon with something else, e.g. a warning sign.

[mzur]

Also the directory tree above the failed file should be colored (but without warning icon).