Fix wrong buffer size calculation.

[buptliuhs]

Summary

The calculation of Buffer size is incorrect (in both v2 and v3).

Motivation

When using OneDriveLargeFileUploadTask to upload small files (usually < 8KB, Buffer.poolSize), buffer size and slice are not calculated correctly, which causes upload failure.

Example of the issue

When uploading a tiny jpeg file whose size is 747 bytes.
Buffer passed in OneDriveLargeFileUploadTask is:
{ byteOffset: 5808, byteLength: 747, length: 747, poolSize: 8192 }

In this case, byteOffset is 5808 and byteLength is 747.
The old code calculates size = byteLength - byteOffset, which is obviously incorrect.

Because of this, the HTTP header that is used later to upload slices will be like:

{
    "content-length": "0",
    "content-range": "bytes 0--5062/-5061",
    ....
}

And it causes a 400 response.

It's likely to happen when the buffer size is less than the pollSize. When buffer is large, byteLength is usually 0.

Test plan

Upload small files (< 8KB) using OneDriveLargeFileUploadTask.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the CONTRIBUTING document.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

[nikithauc]

@buptliuhs Thank you for the contribution!

[nikithauc]

@buptliuhs

1. Can you please provide the error and the steps to reproduce the error?
2. Would it possible to write a unit test identifying this change?

[buptliuhs]

hi @nikithauc,

What I did to reproduce the issue is that uploading a tiny jpeg file whose size is 747 bytes.
Buffer passed in OneDriveLargeFileUploadTask is:
{ byteOffset: 5808, byteLength: 747, length: 747, poolSize: 8192 }

In this case, byteOffset is 5808 and byteLength is 747.
The old code calculate size = byteLength - byteOffset, which is obviously incorrect.

Because of this, the http header will be like:

{
    "content-length": "0",
    "content-range": "bytes 0--5062/-5061",
    ....
}

It's likely to happen when the buffer size is less than the pollSize. When buffer is large, byteLength is usually 0.

I'll see how to add a unit test to cover this change.

Cheers,
Tony

[ghost]

All CLA requirements met.

[buptliuhs]

@nikithauc I had to move some code out of the create method to make the change testable. Hope it is okay.

[buptliuhs]

hi @nikithauc , are you happy with the change?

The base branch was changed.

[nikithauc]

@buptliuhs the changes look good. I changed the base to dev for this PR.

Can you please resolve this?

I should have noticed the base setting before. I apologize for the inconvenience.

[buptliuhs]

Hi @nikithauc, I was initially looking for a fix in v2, which branch should the change be based on? I can create another PR to propagate the fix to dev too to fix the same issue in v3.

[nikithauc]

@buptliuhs Can you please branch off dev? The fix will be reflected in 3.x versions.

[buptliuhs]

Hi @nikithauc , I've done the rebase on the branch and now the branch is based on dev. Please review.
There are some auto-changes as following, hope they are okay:

• package-lock.json: auto-updated when running npm install
• samples/*: auto-updated when running git commit

Again, I'm also looking for the same fix on 2.x since 3.x is still in the preview stage. Is 2.x still in maintenance mode? If yes, which branch should I target? Thanks!

Cheers,
Tony

[nikithauc]

@buptliuhs 3.0.0 is released - https://www.npmjs.com/package/@microsoft/microsoft-graph-client/v/3.0.0. 2.x version will no longer be seeing any changes.

[buptliuhs]

Just did a final tidy-up.

[nikithauc]

@buptliuhs Thank you for this contribution! Merging this right now :)

[buptliuhs]

@nikithauc hello again! Do we have a plan for a new release, e.g. 3.0.1, to include the fixes for 3.0.0? Thanks!

[nikithauc]

@buptliuhs yes. Please expect 3.0.1 soon

[nikithauc]

@buptliuhs https://www.npmjs.com/package/@microsoft/microsoft-graph-client/v/3.0.1