A DirectUpload may fail for several reasons, and return many types of
errors (string, xhr response, Error objects, etc).
For convenience, wrap all these errors in a FileUploadError object.
- It makes easier for clients of the Uploader class to handle errors;
- It allows to propagate the error code and failure responsability.
In Sentry, when an `ActionController::InvalidAuthenticityToken` error
occurs, the breadcrumbs mention that before hitting the error, the user
clicked on one of those links.
Unfortunately we don't know which one. For debugging purposes, adding
classes to the links should allow us to see which links users are
navigating to.
DirectUpload returns errors as strings, including an HTTP status and a
file name (and without a stack trace).
But Sentry groups issues according to the stack trace, and maybe the
error message in last resort.
So we have an issue: as all DirectUpload errors logged by Sentry are
generated on the same line, with random-looking messages, Sentry groups
them either too or too little aggressively.
Instead of creating all the errors on the same line:
- add some `if`s statements to create them on different lines (and so
with different stack traces),
- strip the file name from the error message.
This allows Sentry to group the errors properly, with meaningful error
messages.
When the authenticity token is invalid, the creation of the blob before
the direct upload returns a 422.
In that case, the token will never become valid again, and it is useless
to try again. Don’t show the "Retry" button in this case.
NB: of course the real fix is to understand why the authenticity token
is so often invalid – but this will be for later.
When cliking on the "Delete attachment" link, and opening the URL
in a new tab, the `DELETE /attachements/:id` will become
`GET /attachments/:id` – which will cause the `show` action to be
routed with an html format (instead of JS).
In that case, we don't want to throw an error at the user face.
Instead simply re-render the dossier page (if any).
Fix a long-standing error in Sentry.
Pooling for attachment status is a background operation. Errors should
not be reported to the user, who didn't even ask for this operation to
take place.
This is why we ignore all errors, whether Javascript exceptions or
network errors.
