Bug when creating an UploadSession with the SDK.

[hassanacto]

Hi,

We're seeing a very weird bug where we receive a 400 bad request error when trying to create an upload session. I say weird because it happens some times, and not others. We first noticed it while performing a migration and moving over about 900 office documents.

Here's our code sample:

return $this->graph->createRequest(
            "POST",
            "/drive/root:/{$upload_folder_path}/{$file_name}:/createUploadSession"
        )
            ->attachBody(
                [
                    "@microsoft.graph.conflictBehavior" => "rename | replace | fail",
                    "fileSystemInfo" => ["@odata.type" => "microsoft.graph.fileSystemInfo"],
                    "description" => "description",
                    "name" => "{$file_name}",
                ]
            )
            ->setReturnType(UploadSession::class)
            ->execute();

AB#9348

[Ndiritu]

Hi @hassanacto. Thanks for reporting this. Are you able to share the response payload(s) you get for the 400's?

[Ndiritu]

I've tried reproducing this using the code snippet you've provided and I seem to get 200s somewhat consistently. The erratic 400s still need to be looked into.

However I noticed some issues with the payload structure in the body...

• Ideally the data you're currently submitting should be nested under an "item" attribute from the docs
• The value for @microsoft.graph.conflictBehavior should only contain one of the 3 options
• fileSystemInfo should contain a FileSystemInfo object

What version of the SDK are you using? It's not clear from the snippet

[hassanacto]

Hi @Ndiritu! I'll try to look at our logs and see if I can share the request payloads. We've only run into this since we started doing a heavy client migration. I remember constructing our request payload according to the docs, but that was last updated in 2019 (it's quite possible our version is out of date).

Our Graph SDK version is 1.11.

I'll try to update our SDK version and modify our requests before coming back. It could just be due to our outdated version.

[Ndiritu]

@hassanacto sorry I actually meant to ask what version of the API you're using (v1 or beta) but I'm guessing v1?

I think your SDK version shouldn't be much of an issue since there should be no breaking changes between your version and the latest one (only made minor releases so far).

Please share your outcome after modifying the request payload and incase of any 400s, please share the response body accompanying the 400.

[MIchaelMainer]

Can you please provide a requestId and time stamp from the 400 response? If you can share a sanitized request and response that would be helpful as well (the response will contain the requestId and time stamp).

@ificator for visibility.

[ificator]

SharePoint did have an issue with seemingly random 400 responses, but that should have been resolved for a while now. Are you still seeing the 400s occurring?

[Ndiritu]

No further correspondence from OP. Closing this.