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

Intermittent 400 Bad Request response for createUploadSession #1064

Closed
2 of 3 tasks
dangerbell opened this issue May 10, 2019 · 5 comments
Closed
2 of 3 tasks

Intermittent 400 Bad Request response for createUploadSession #1064

dangerbell opened this issue May 10, 2019 · 5 comments

Comments

@dangerbell
Copy link

Category

  • Question
  • Documentation issue
  • Bug

Expected or Desired Behavior

No error response from createUploadSession.

Observed Behavior

We're long time users of the OneDrive API, but for some reason we can't figure out we're now getting a lot of error responses from API calls that used to work without problem.

It seems to be isolated to the oneDrive.createUploadSession api call.

We have a regular test suite that includes uploading several files. Mostly createUploadSession works, but sometimes it fails with the following error response:
{"error":{"code":"invalidRequest","message":"Bad Argument"}}

A retry of the exact same request will sometimes succeed and sometimes fail. There's no pattern to the failures that I've been able to figure out. Different files fail each time I run the test. Different number of retries.

Doesn't seem to be a request limit issue. There's no backoff response and even with very long delays between requests there are still failures.

#870 Seems similar, but that issue is supposed to be resolved. Changing the request body as mentioned in the other issue doesn't change the behaviour.

Example of failing request/response:

POST https://api.onedrive.com/v1.0/drive/items/993A547F8BF1AB5D!233962:/2012-01-17%2011.57.18.JPG:/oneDrive.createUploadSession?select=id%2Cname%2Csize%2CeTag%2CfileSystemInfo%2Cfile%2Cfolder%2Cpackage%2Csharepointids%2ClastModifiedDateTime%2C%40content.downloadUrl%2CwebUrl%2CwebDavUrl 

headers:
  "Content-Length":"126",
  "accept":"application/json"
  "Content-Type":"application/json"
  "Host":"api.onedrive.com"
  "User-Agent":"ISV|mover|mover/1.0"

body:
{
  "item": {
    "@microsoft.graph.conflictBehavior":"replace",
    "fileSystemInfo": {
      "lastModifiedDateTime":"2019-05-10T20:57:14+00:00"
    }
  }
}
headers:
  "Via":"1.1 BY3PPF98109C930 (wls-colorado)",
  "Content-Length":"60",
  "Content-Type":"application/json",
  "Vary":"Accept,Accept-Language,Authorization,Prefer",
  "X-WLSPROXY":"BY3PPF98109C930",
  "X-MSNSERVER":"CH1AAPB436FC1D4",
  "X-QosStats":"{"ApiId":0,"ResultType":2,"SourcePropertyId":0,"TargetPropertyId":42}",
  "X-ThrowSite":"1d9a.aa36",
  "X-VroomVersion":"v1.0",
  "X-AsmVersion":"UNKNOWN; 19.246.503.2005",
  "X-MSEdge-Ref":"Ref A: DFF1815564B44CF6BD171E8FE521D751 Ref B: WSTEDGE1017 Ref C: 2019-05-10T20:31:46Z",
  "Date":"Fri, 10 May 2019 20:31:46 GMT"

body:
{
  "error": {
    "code": "invalidRequest",
    "message":"Bad Argument"
  }
}

Steps to Reproduce

As far as I can tell just using createUploadSession will cause this problem. But it's probably not just that. I can provide account information privately.

Thank you.

@ghost ghost added the Needs: Triage 🔍 Needs initial triage assessment label May 10, 2019
@ghost
Copy link

ghost commented May 10, 2019

Thank you for your contribution to OneDrive API Docs. We will be triaging your incoming issue as soon as possible.

@ificator
Copy link
Contributor

Thanks @dangerbell we noticed this ourselves and believe we found the cause. Please let us know if you're still seeing issues.

@ificator ificator self-assigned this May 10, 2019
@ificator ificator added type:bug and removed Needs: Triage 🔍 Needs initial triage assessment labels May 10, 2019
@dangerbell
Copy link
Author

I'm not seeing it with our tests anymore. Thank you!

Can you elaborate on what the problem was?

Is this fixed globally? We have clients who run uploads through our service, so if the fix is rolling out could you tell me when it would be complete?

@ificator
Copy link
Contributor

Thanks for confirming.

I can't go into details on what the actual problem was, but I can say that once it was detected the process of disabling the code that was causing it was very quick. So by the time you saw resolution all of your clients would have as well.

@RouR
Copy link

RouR commented Apr 5, 2022

I have similar issue at this moment.

I found reason of this.
You (and me) set only lastModifiedDateTime.
Just add CreatedDateTime.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants