Sp-dev-docs: AADHttpClient failing to renew token with timeout

[westleyMS]

Category

• [x] Bug

Describe the bug

Intermittently, when a token gets refreshed (after inactivity) the iframe will get created by the AADHttpClient, and it will get the token, but in the page where the token is granted, it uses the document.location.rewrite(""), and the browser never sends that request, after about 10 seconds, the AADHttpClient throws a timeout error something like this-

Error - Type : Token Renewal Failed - Description : Token renewal operation failed due to timeout - AADCorrelationId: <_guid_> - ClientId: <_guid_>

Upon re-fresh, the next call works fine.

This happens in several browsers - Chrome/Edge/Firefox/IE

Reproduction steps-

1. Go to the SharePoint site and log in
2. Wait for token expiry
3. Navigate to the page with the custom web parts on it

Expected behavior

web parts consistently call an Azure function and then load with the retrieved data

Environment details (production environment)

All Windows/Mac machines
All known browsers in use Chrome/Edge/Firefox/IE
On connected corp net and from home users, with and without VPN, so it doesn't appear to be a network issue.

[msft-github-bot]

Thank you for reporting this issue. We will be triaging your incoming issue as soon as possible.

[sortegamartin]

In our clients we are having the same problem, when a tab is left open and the token expires, when fetching with the aadhttpclient, the promise remains pending and is not resolved.

This is a critical problem since our webparts don't work again until the user refreshes the page.

[andrewconnell]

Smells like a dupe #4892... can you please confirm @westleyMS ?

[westleyMS]

Not a dupe, very similar, but in this case we see a timeout error, but the token is returned, and it is not blocked by the sandbox attributes like in #4892 . Also, the login.microsoftonline.com site doesn't give the token in a 302, but in a full 200 response with script in the body to make the window redirect, which it doesn't do. This does seem like some underlying issue with possibly the ADAL.js library and some strange race condition on refresh that manifests when there are various other issues.

[westleyMS]

This was resolved at the end of July by an update by the MS product group.

[jkondakindi]

Hello, can you please provide more details on the resolution. When was this pushed to the tenants?

We are currently experiencing issues with AadHttpClient in our SPFx web parts that consume Azure AD-Secured APIs. The first time user accesses a page with an SPFx web part that consumes an Azure AD-Secured API it works fine. But after a period of inactivity like 30 mins, if the user tries to access the same page or another page with another SPFx web part that makes an Azure AD-Secured API call the request fails with a 401 unauthorized error. Based on our troubleshooting, the AadHttpClient is still using an expired access token from a previous session. The older access token gets cached and there is no way to get out of this. Closing the browser or clearing browser cache doesn't resolve this issue. This is the same behavior in new Edge and Chrome.

SharePoint Online REST APIs are working fine. We have a few pages that have multiple web parts and the web parts consuming SPO APIs are working fine but the ones consuming Azure AD-Secured APIs are failing.

We are currently experiencing production outages due to this issue. A critical case was opened with Microsoft yesterday but seems like we are having very hard time trying to get to the product team. This is absolutely frustrating as our hands are totally tied and we are not getting much help from Microsoft.

[westleyMS]

I believe it was finished rolling out on 7/24, and we had several confirmations that it fixed our open issues. This issue was specifically with the token refresh failing, it call the auth endpoint and get the token, and then never use it and throw a timeout error. We have seen some other issues but they are not the same as this one. The AADHttpClient should check the expiration before making the call and if it is past (or really close) it will get a new token. I would like to see the process of the refresh or see it try to get the token to see what is happening. If it never tries to get the token, that might be a new issue. I would open a new ticket on this, and try to find information specifically on the acquisition of the token via F12 network tool or fiddler. Be aware that these traces may contain sensitive info so be careful when sharing.

[andrewconnell]

See this comment for details on the fix... https://github.com/SharePoint/sp-dev-docs/issues/4892#issuecomment-663165736

My understanding is that this issue is directly related to that one, so I'm going to mark this as a dupe. If that's not correct, simply reply with how it's different... thanks!

[msft-github-bot]

Closing this issue as a dupe. Please refer to our wiki for more details: Issue List Labels: status:duplicate