I have two processes that run at roughly the same time and generate ~40gb PDFs. Each process uploads the PDFs to the same SharePoint site. The second request fails with this error:
05:11:19.204 [0033] Office365SharepointOutput encountered an error :
{“code”:429,“Retry-After”:“60,120”,
“body”:
{“error”:
{“code”:“activityLimitReached”,“message”:“The request has been throttled”,
“innerError”:
{“code”:“throttledRequest”,
“innerError”:{“code”:“quota”},
“date”:“2026-09-17T12:11:19”,
“request-id”:“838172d4-e970-4631-b898-fb4c9909ed59”,
“client-request-id”:“838172d4-e970-4631-b898-fb4c9909ed59”}}}}
My theory is that the first upload is still ongoing when the second starts, and that the plugin isn’t respecting the “Retry-After” response. From an MS site:
Respect Retry-After: Read the wait time specified in the response header and pause your code before sending new requests.
If this is the case the obvious workaround would be to have single process upload to SharePoint365 and have both your processes call it. Since in Workflow process are synchronous, the issue would be bypass.
Tom: The problem isn’t caused by the concurrency of operations so much as the volume. You could very well upload two small PDF files concurrently and wouldn’t receive the 429 error message.
Yet I’m not sure the plugin should automatically attempt to retry after the specified wait time: while it’s waiting, some other process might keep uploading small files, just short of the throttling limit, and your plugin might appear to stay stuck for however long it takes. Which could have an impact on any of the subsequent tasks in your process.
But I do think an option in the plugin’s UI to Retry on throttle error could be useful, as long as the user understands the potential consequences.
Thanks, yes, I understand from some research that it’s a mix of volume and concurrency. My workaround is to stagger the start times of the two processes so that there’s a 1.5hr gap between them.
So a single synchronous Process for all SharePoint uploads. I like that idea. That would solve any “concurrency limit” traffic jams, but there’s also volume limits. Queuing up several large uploads one after the other could still potentially hit a limit and generate a 429. I wonder if there is a way to Query SharePoint before an upload to get a status.
If you know the limit and said limit only apply starting at a fix size, you could setup a script that waits for a time until it is good to go and then continue whit the upload. But yeah, if you can query SharePoint to know when it’s good to go that would be even better.
Unfortunately, there’s no way of querying SharePoint about its throttling status.
So as JC suggested, you could explore adding a delay programmatically when the plugin returns an 429 error (using Watch.Sleep()). You could make it so that the number of retries is limited so that your process isn’t stuck in an infinite loop.