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

RateLimit headers are not returned by SharePoint online #10069

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

RateLimit headers are not returned by SharePoint online #10069

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

digiofficerobin commented Jan 8, 2025

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.25110.12000
  • .NET framework 4.8

Describe the bug / error

We have an RateLimit implementation based on this example on GitHub: https://github.com/OneDrive/samples/blob/master/scenarios/throttling-ratelimit-handling/readme.md

In a development environment we get RateLimit headers returned from SharePoint, but with ClientIDs from a few customers we almost never get RateLimit headers returned.

Instead the customer app is throttled with 429 Too Many Requests errors with retry times of sometimes even 200+ seconds.

In Fiddler the network traffic is clearly visible that there are no RateLimit headers.

NoRateLimitHeaders

In the production environment there are around 4 processes which run with the same clientid which do background processes (Windows agents), and 4 processes (websites) which serve user requests. The websites processes run under a different clientid, but this does not make a difference. All processes are affected with many 429 errors.

In which case does SharePoint online give not first RateLimit headers, but returns 429 errors?

Steps to reproduce

  1. Use the example on GitHub https://github.com/OneDrive/samples/blob/master/scenarios/throttling-ratelimit-handling/readme.md
  2. Change the function SharePointCSOMCallAsync
private async Task SharePointCSOMCallAsync(Microsoft.SharePoint.Client.ClientContext clientContext)
{
	var site = clientContext.Site;
	var rootWeb = site.RootWeb;
	var contentTypes = rootWeb.ContentTypes;
	var currentUser = rootWeb.CurrentUser;
	var fields = rootWeb.Fields;

	clientContext.Load(site, s => s.Url, s => s.ServerRelativeUrl);

	clientContext.Load(rootWeb, r => r.Id, r => r.Description, r => r.Title, r => r.Url);
	clientContext.Load(rootWeb, r => r.Language, r => r.ServerRelativeUrl);

	clientContext.Load(currentUser, u => u.IsSiteAdmin, u => u.LoginName);

	clientContext.Load(contentTypes, c => c.Include(ctt => ctt.Fields.Include(f => f.InternalName), cct => cct.FieldLinks.Include(fl => fl.Name), ctt => ctt.Name, ctt => ctt.Group));
	clientContext.Load(fields, fi => fi.Include(f => f.InternalName, f => f.Id, f => f.Group, f => f.Hidden, f => f.ReadOnlyField, f => f.Title, f => f.CanBeDeleted));

	clientContext.Load(rootWeb, r => r.RoleDefinitions.Where(rd => !(rd.RoleTypeKind == RoleType.Guest || rd.RoleTypeKind == RoleType.RestrictedGuest)).Include(rd => rd.Id, rd => rd.Name, rd => rd.BasePermissions, rd => rd.RoleTypeKind));
	clientContext.Load(rootWeb, r => r.RoleAssignments.Include(ra => ra.Member.LoginName, ra => ra.Member.PrincipalType, ra => ra.Member.Id, ra => ra.RoleDefinitionBindings.Include(rdb => rdb.Id, rdb => rdb.RoleTypeKind, rdb => rdb.Name)));

	var siteUsers = site.RootWeb.SiteUsers;
	site.RootWeb.Context.Load(siteUsers, us => us.Include(u => u.Title, u => u.LoginName, u => u.PrincipalType, u => u.Email, u => u.Id));
	loadDefaultTitleDescriptionResource(clientContext.Site.RootWeb);
	await clientContext.ExecuteQueryAsync();
	Console.WriteLine(site.RootWeb.Title);

	IncrementCallsDone();

}

private static void loadDefaultTitleDescriptionResource(Microsoft.SharePoint.Client.Web web)
{
	var cultureNameEN = "en-US";
	var cultureNameNL = "nl-NL";
	_ = web.TitleResource.GetValueForUICulture(cultureNameEN);
	_ = web.TitleResource.GetValueForUICulture(cultureNameNL);
	_ = web.DescriptionResource.GetValueForUICulture(cultureNameEN);
	_ = web.DescriptionResource.GetValueForUICulture(cultureNameNL);
}
  1. Comment method 'SharePointRestCallAsync' and 'GraphRestCallAsync', so only method 'SharePointCSOMCallAsync' is called.
// Test a SharePoint Rest call
// await SharePointRestCallAsync(client, sharePointAccessToken);

// Test a Graph Rest call
//await GraphRestCallAsync(client, graphAccessToken);

// Test a CSOM call
await SharePointCSOMCallAsync(clientContext);
  1. Configure the app (for instance with 5 threads)
  2. Start Fiddler (or any other app which can show network traffic)
  3. Run the app

Expected behavior

In the development environment we get RateLimit headers.

RateLimitHeaders
@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