Sp-dev-docs: When using AadHttpClient or MSGraphClient in multiple web parts on the same page it causes token fetch issues

[estruyf]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

Expected or Desired Behavior

When using the AadHttpClient or MSGraphClient in multiple web part on the same page, it would be great if the token fetching works seamlessly.

Observed Behavior

When loading multiple web parts on the same page which make use of the AadHttpClient or MSGraphClient, it causes issues when fetching the access token on the first try. Here you see a sample of three web parts which are using the MSGraphClient. When I do an initial page load (token not yet in sessionStorage), only one will retrieve the token, the two others fail:

Above screenshot is in Chrome. When I load it in Firefox, all three web parts fail:

When refreshing the page, all is good because the token is cached.

Should be impossible

Error: Should be impossible.
Stack trace:
__WEBPACK_AMD_DEFINE_RESULT__</</ge</e.prototype._loginUser/<@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:36172
__WEBPACK_AMD_DEFINE_RESULT__</</ge</e.prototype._loginUser/</<@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:35438
__WEBPACK_AMD_DEFINE_RESULT__</</ge</e.prototype._startLogin/this._displayCallHandler@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:34984
displayCall@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:34827
[6]/i</i.prototype.login@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/0.sp-http-adal_4a41848c866052caa755.js:3:3670
__WEBPACK_AMD_DEFINE_RESULT__</</ge</e.prototype._startLogin@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:35025
__WEBPACK_AMD_DEFINE_RESULT__</</ge</e.prototype._loginUser/<@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:35405

Window closed without authenticating

Error: Login popup failed to redirect to the designated redirect uri.
Stack trace:
__WEBPACK_AMD_DEFINE_RESULT__</</ge</e.prototype._waitForWindowToClose/</s<@https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-03-23.011/sp-pages-assembly_en-us_325b8f8982f9db16bb747bf1b7651f15.js:688:36475
RecentlyUsedDocuments.tsx:50:10

Steps to Reproduce

• Add multiple web parts to a page which will do a call to fetch an access token.

[justdevelopment]

We also have this issue, however it won’t load at all most of the time and usually there's no error at all. With enough refreshing in Chrome you can get lucky; it will load one webpart and then after refresh everything is working. We haven’t been able to get that in either Edge or IE11, the token is never loaded and none of the webparts load properly.

I think I’ve managed to narrow it down to how the client fetches the token. It seems to be running a recursive loop to get a token from cache or from graph, but because there are multiple webparts on the page all calling the same thing it enters a race condition and never correctly gets a token. You end up in a catch somewhere deep in the SPO javascript, thus no visible error. I assume it’s logged somewhere we can’t see? When you’re lucky with loading/running order(?) it will manage to get a token after which you’re good to go.

This issue seems to have shown up sometime last week. I think maybe it’s related to the (apparent) removal of the popup? When I use code below there is no popup, at least not visibly, for logging in (yay).

To work around the issue I’m using a semaphore. It makes the page really slow when you have a lot of graph stuff, since effectively you remove all async-ness from it but at least all webparts load without error. I’ve created a demo solution here;
https://github.com/justdevelopment/SPFxDemo/tree/Semaphore

It’s not the best code. I’m storing stuff in a global variable which then all other webparts need to use (meaning, another party’s webpart with a graph call will still break your entire page). We need to run the actual call for it to get a token. Just creating the client isn’t enough to kick off fetching a token and the get token function in the client isn’t usable without copying just about everything to our code. Still, it's a workable solution but obviously we're anxious for a real fix :-)

[StefanWaalderbos]

Some news/progress on this for us important issue?

[ghost]

The original issue has been fixed already. We're working on a fix to prevent issues with multiple token requests. I'll update this thread when the fix has been rolled out.

[StefanWaalderbos]

Thank you lahuey. We looking forward to this as it is a issue for our product in development at this time.

[BraunJonathan]

That's a good news !
We looking forward to this fix too, as we are using 4 or 5 custom webparts with MSGraphClient on the same page and having all working at the same time is a nightmare right now !!