Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ReadError: file could not be opened successfully #65

Closed
sentry-io bot opened this issue Aug 31, 2020 · 1 comment
Closed

ReadError: file could not be opened successfully #65

sentry-io bot opened this issue Aug 31, 2020 · 1 comment

Comments

@sentry-io
Copy link

sentry-io bot commented Aug 31, 2020 •
edited by TrueBrain

Sentry Issue: BANANAS-API-D

ReadError: file could not be opened successfully
(1 additional frame(s) were not displayed)
...
  File "aiohttp/web_app.py", line 458, in _handle
    resp = await handler(request)
  File "bananas_api/web_routes/new.py", line 92, in tusd_handler
    add_file(
  File "bananas_api/new_upload/session.py", line 236, in add_file
    session["files"].extend(extract_tarball(new_file))
  File "bananas_api/new_upload/extract.py", line 79, in extract_tarball
    with tarfile.open(file_info["internal_filename"]) as tar:
  File "tarfile.py", line 1604, in open
    raise ReadError("file could not be opened successfully")

Error handling request
@TrueBrain
Copy link
Member

In short, the user uploaded a zero byte tarball, which failed to open (as it should). Correctly an exception was raised, and this was propagated to the frontend as a 500 error (which is also fine), but in the backend this ticket was generated (which is not fine).

Please check what the best way is to propagate exceptions from the tus-handler back to the frontend, where it is clear for the user what went wrong, and doesn't generate exceptions on invalid tars/zips/etc.

TrueBrain added a commit to TrueBrain/OpenTTD-bananas-api that referenced this issue Sep 2, 2020
@TrueBrain
Fix OpenTTD#65: ignore errors in tarballs/zipfiles
352284d 
There currently isn't really a way to talk back to the client that
they uploaded an invalid tarball/zipfile. So far this only happened
when someone uploaded a zero-byte tarball, which is pretty obvious.
Hopefully that remains this way.

The behaviour is now: if you upload an invalid tarball/zipfile,
after pressing validate, the file is no longer in the filelist.
Hopefully that gives enough clues to the user what is going on.
TrueBrain added a commit to TrueBrain/OpenTTD-bananas-api that referenced this issue Sep 2, 2020
@TrueBrain
Fix OpenTTD#65: report errors in tarballs/zipfiles
6568628 
This is a bit of a hack in comparison with the normal validation
method, but these errors happen on upload, where the other errors
happen on validation.

Sadly, the tusd implementation is a bit wonky, and we cannot really
communicate back with the client when we found such error during
upload (as strictly seen the upload succeeded fine; the content
is broken). So we cannot report the error on upload, and as such
are forced to do it after upload.
TrueBrain added a commit to TrueBrain/OpenTTD-bananas-api that referenced this issue Sep 2, 2020
@TrueBrain
Fix OpenTTD#65: report errors in tarballs/zipfiles to the user
094aa77 
This is a bit of a hack in comparison with the normal validation
method, but these errors happen on upload, where the other errors
happen on validation.

Sadly, the tusd implementation is a bit wonky, and we cannot really
communicate back with the client when we found such error during
upload (as strictly seen the upload succeeded fine; the content
is broken). So we cannot report the error on upload, and as such
are forced to do it after upload.
TrueBrain added a commit to TrueBrain/OpenTTD-bananas-api that referenced this issue Sep 2, 2020
@TrueBrain
Fix OpenTTD#65: report errors in tarballs/zipfiles to the user
81583d0 
This is a bit of a hack in comparison with the normal validation
method, but these errors happen on upload, where the other errors
happen on validation.

Sadly, the tusd implementation is a bit wonky, and we cannot really
communicate back with the client when we found such error during
upload (as strictly seen the upload succeeded fine; the content
is broken). So we cannot report the error on upload, and as such
are forced to do it after upload.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@TrueBrain