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

Show an unexpected error when trying uploading a page blob not in a multiple of 512 bytes #1050

Closed
v-xianya opened this issue Jan 8, 2019 · 3 comments

Comments

@v-xianya
Copy link
Member

@v-xianya v-xianya commented Jan 8, 2019

Storage Explorer Version: 1.6.2
Platform/OS Version: Windows 10/MacOS High Sierra/ Linux Ubuntu 16.04
Architecture: ia32/x64
Build Number: 20190108.1
Commit: 1d51960b
Regression From: Regression from 1.5.0 release (build: 20181026.3)

Steps to Reproduce:

  1. Uncheck 'Use AzCopy for Improved Blob Upload and Download' under Experimental.
  2. Expand a non-ADLS account -> Blob Containers -> Create a new blob container.
  3. Upload a file as page blob that isn't a multiple of 512 bytes in length to it.
  4. Check the Activities.

Expected Experience:

Show errors like the below:
image

Actual Experience:

Show the below error messages in Activities.
image
Detail: {"message":""Upload failed unexpectedly after 5 attempt""}

@craxal

This comment has been minimized.

Copy link
Contributor

@craxal craxal commented Jan 8, 2019

Not sure what’s happening with the error message, but this is just one example of a more general case I’ve noticed. They’re not getting “swallowed”. They’re just getting aggregated in an object somewhere. We’ll want to revisit error passing at some point and clean up a few things.

@craxal craxal added the 🐞 bug label Feb 15, 2019
@craxal craxal added this to Committed in Storage Explorer via automation Feb 15, 2019
@craxal craxal added this to the 1.8.0 milestone Feb 15, 2019
@craxal craxal self-assigned this Feb 15, 2019
@craxal

This comment has been minimized.

Copy link
Contributor

@craxal craxal commented Apr 2, 2019

Drilled down into the storage client library and found out they're explicitely throwing an error in a callback instead of passing the error to our callback. Since callbacks are asynchronous, the original try/catch context is lost, and therefore there's no way for us to properly catch and handle it.

@XiaoningLiu, can we get this fixed?

@craxal

This comment has been minimized.

Copy link
Contributor

@craxal craxal commented Apr 11, 2019

We can add a workaround where we check the file size manually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.