Pnpjs: SPFX throttling and 503 errors

[ng-marcus]

Category

• [ ] Enhancement
• [ ] Bug
• [X] Question
• [ ] Documentation gap/issue

Version .

Please specify what version of the library you are using: [ 1.3.5 ]

Please specify what version(s) of SharePoint you are targeting: [ Online ]

Expected / Desired Behavior / Question

API access to SharePoint without throttling.

Observed Behavior

Even under very light load of one user running our Spfx app against a very small data set, we are getting 503 Server Busy errors. This varies between our tenants - some see it rarely, others see it continually. We are concerned that such light usage is triggering this error.

The recommendation is to tag the User Agent with ISV and other information. However, when making these calls in the browser, setting the User Agent is not allowed.

I know we can't know concrete numbers, but we are making a small number of API calls but triggering the error. Would having the user agent header help here or should we look elsewhere?

Steps to Reproduce

Normal usage of Spfx calls to the /_api/web API endpoint.

[koltyakov]

I’d suggest checking if there are some logical errors in the code. E.g. due to some mistakes the webpart/app customizer bombarding the API and you got throttled even without knowing it.

I’d recommend monitoring the traffic with fiddler and analyze numbers end endpoints. Maybe you’re doing half of that 4 billion of calls in a month throughout the world. ;). Just kidding, but without numbers or at least code usage samples it’s hard to say.

In my experience, we have tenants with intensive consumption of the API and zero throttling. The only time I got throttled when on test purposes send thousands item create operations in parallel.

[ng-marcus]

We've run through the code and there's no obvious place where we hit the server too often. We can see the Sharepoint health go from 0 to 10 very quickly though :( . Probably the most intensive thing we do is set up a new site when we will add about 15 lists, and add about 20 items to each, apart from one where we add about 450 items. Those are done in batches of 50. All small items though, e.g. list items of two columns of text fields, not files.

Otherwise we might read 50 items from a list, with a lookup to another list. Then add a couple of list items. And this is one user on our stage tenancy.

Thanks for the feedback though, we feared our product was doomed if we couldn't make more than a tiny number of API calls! It sounds like you're using it without issue so there is hope! Do you decorate your requests in any way (special header etc?) or is the app registered with Microsoft?

I'll collect some stats too on actual code calls.

Thanks!

[ng-marcus]

To follow this up, I think it's an infrastructure issue rather than a throttling issue. It's giving 503 errors even when loading list file attachments, so not even our API.

We've fixed the issue by using our own fetch and catching and retrying on a 503 - we've seen every 503 request so far return as a success on the next try.

[patrick-rodgers]

Depending on what you are doing and how you are doing it PnPjs is written to retry on 503, meaning if you have a lot of parallel operations that might all get caught in a cycle of retry it could add load. The library is used highly by many tenants, so I don't believe we have an internal issue that would generate throttling.

There is no way to add the header from the browser, I have had that conversation with the appropriate PG folks. There are also no special registrations being done to allow higher usage.

I would follow @koltyakov suggestions - my guess would be there is something happening you aren't aware of. One example I have seen is where folks have a setTimeout with a 5 instead of 5000. Sometimes little things can get you.

Going to close this issue as it is answered. If you do find a place where we are forcing you to be throttled please open a new issue, reference this one, and let us know so we can help out.

[ng-marcus]

Hi Patrick,

A couple of things. It's not the library that we thought was causing the 503 errors, more that we thought we might be doing something wrong in our app.

Regarding 503 catching, this seems to be caught when using the Node version, but we had to overwrite fetch and catch the 503 error ourselves in the browser version. If this isn't intentional, let me know and I'll open a new issue.

[patrick-rodgers]

Hmmm...if you have more details we can take a look. It runs the same code in browser or node for the throttling so if it works in one place it should work in the other, but perhaps we missed something.

[ng-marcus]

Copying in my colleage @allanchaplin who worked on this. We saw 503 errors coming through to us so he over-rode fetch to catch them.

[patrick-rodgers]

You would expect to see those if we do the max number of retries we return the 503.

[ng-marcus]

I think then it's all working as it should. We will open another issue if we see a problem

Thanks again!