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

Quota is not reset after waiting RateLimit-Reset time #10070

Open
1 of 9 tasks
digiofficerobin opened this issue Jan 8, 2025 · 0 comments
Open
1 of 9 tasks

Quota is not reset after waiting RateLimit-Reset time #10070

digiofficerobin opened this issue Jan 8, 2025 · 0 comments
Labels
type:bug-suspected Suspected bug (not working as designed/expected). See “type:bug-confirmed” for confirmed bugs.

Comments

@digiofficerobin
Copy link

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

SharePoint CSOM

Developer environment

Windows

What browser(s) / client(s) have you tested

  • 💥 Internet Explorer
  • 💥 Microsoft Edge
  • 💥 Google Chrome
  • 💥 FireFox
  • 💥 Safari
  • mobile (iOS/iPadOS)
  • mobile (Android)
  • not applicable
  • other (enter in the "Additional environment details" area below)

Additional environment details

  • Microsoft.SharePointOnline.CSOM 16.1.22810.12000
  • .NET 6

Describe the bug / error

While developing and testing the RateLimit headers which SharePoint online provides we noticed that the RateLimit-Reset value does not imply the number of seconds an app should wait before the quota is fully reset.

RateLimit-Reset

In the documentation https://learn.microsoft.com/en-us/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online is stated that RateLimit-Reset value is the number of seconds before the quota is reset.

In our testing we see that after we wait the number of seconds specified by the RateLimit-Reset value the quota is not reset. In this example the quota is reset after 26 seconds instead of 5 seconds.

Steps to reproduce

  1. Use the example provided by https://github.com/OneDrive/samples/blob/master/scenarios/throttling-ratelimit-handling/readme.md
  2. Modify the following lines InitializeAndRunAsync() method in Demo.cs:

From:
parallelOps.Add(DoWork(j, client, sharePointAccessToken, graphAccessToken, 5000));

To:

                if (j == 0)
                {
                    parallelOps.Add(DoWork(j, client, sharePointAccessToken, graphAccessToken, 5000));
                }
                else
                {
		  parallelOps.Add(DoWork(j, client, sharePointAccessToken, graphAccessToken, 90));
		}
  1. Use this RateLimiter.cs file (uploaded as txt file)
    RateLimiter.cs.txt

  2. In Demo.cs we have changed the code of SharePointCSOMCallAsync() method to make a EnsureUser call to SharePoint online.

        private async Task SharePointCSOMCallAsync(Microsoft.SharePoint.Client.ClientContext clientContext)
        {
            // Make a CSOM call
            var refUserAsPrincipal = clientContext.Web.EnsureUser("ADSynctest-01"); // 2 punten
			clientContext.Load(refUserAsPrincipal, _user => _user.Email, _user => _user.LoginName);

			await clientContext.ExecuteQueryAsync();
			//clientContext.Load(clientContext.Web);
			//await clientContext.ExecuteQueryAsync();
			IncrementCallsDone();

            //Console.WriteLine(clientContext.Web.Title);
        }
  1. In Demo.cs we commented out the following lines:
                // Test a SharePoint Rest call
               // await SharePointRestCallAsync(client, sharePointAccessToken);

                // Test a Graph Rest call
                //await GraphRestCallAsync(client, graphAccessToken);
  1. Run the example

Expected behavior

We expect that after waiting the RateLimit-Reset value in seconds the quota is reset and the folllow up requests can go full throttle.

@digiofficerobin digiofficerobin added the type:bug-suspected Suspected bug (not working as designed/expected). See “type:bug-confirmed” for confirmed bugs. label Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:bug-suspected Suspected bug (not working as designed/expected). See “type:bug-confirmed” for confirmed bugs.
Projects
None yet
Development

No branches or pull requests

1 participant