[BUG] applicationinsights.azure.com/v2/track making hundreds of thousands of requests when third party cookies are disabled

[kbeeveer46]

EDIT: The following issue below occurs in version 3.0.4 and 3.0.5 but NOT 3.0.3.

We are currently using App Insights inside custom webparts in SharePoint Online in a React/TypeScript project. When I disabled third party cookies in Chrome to test a SharePoint feature the entire browser locks up. When I looked at the network tab in the dev tools it says there are hundreds of thousands of requests from https://centralus-2.in.applicationinsights.azure.com/v2/track. I stopped it when it got to 100,000 but I don't think it ever stops on it's own. I saw it hit 300,000 one time. I was able to see the request payload and it looked like this but instead of 3 commas there were thousands of commas inside a beginning and ending bracket.

[,,,]

I tried setting "disableCookiesUsage" to true but that didn't change anything (I'm not sure what that setting does). I thought it might be failing and retrying over and over so I also tried setting "isRetryDisabled" to true but that didn't change anything, either. When I enable third party cookies the tracking URL only shows up once in the network tab.

Is this typical behavior? Is there a way to disable app insights when third party cookies are disabled or is there a setting I need to use? SharePoint Online doesn't like it when third party cookies are disabled. Is it possible no third party cookies + SharePoint Online + App Insights combined is causing some unintended things to happen?

Here is a screen shot.

Here is a screen shot of the errors tab. The 2 errors at the bottom were in the log around 10 times. A new one would pop up every few seconds until I stopped logging

Here is my config

@microsoft/applicationinsights-web": "^3.0.5"

const applicationInsights = new ApplicationInsights({
          config: {
              connectionString: Settings.CONNECTION_STRING_APP_INSIGHTS,
              namePrefix: this.context.pageContext.web.title,
              accountId: siteName,
              disableFetchTracking: true,
              disableAjaxTracking: true,
              disableExceptionTracking: true,
              autoTrackPageVisitTime: true,
              enableDebug: true
          }
      });

applicationInsights.loadAppInsights();
applicationInsights.setAuthenticatedUserContext(this.context.pageContext.user.email);
applicationInsights.context.application.ver = this.packageSolution?.solution?.version;

Let me know if I need to provide any more info. This is my first App Insights GitHub ticket.

[Mohamed-Ahmed-Abdullah]

I got the same issue,

• I'm using App insight with Adobe AEM (React 16)
• @microsoft/applicationinsights-react-js": "^2.5.4", "@microsoft/applicationinsights-web": "^3.0.5"
• Intermittently I see hundreds or tens of thousands of requests Most of them are ping in chrome network tab the column type is ping
• So I added this to my code base appInsights.addTelemetryInitializer((envelope) => { if (envelope.data.baseType === "PingData") { return false; } return true; });

That seems to did the trick but since it's an intermittent issue it's hard to tell with accuracy if that fixed it or not.

[alfeg]

Confirm on my side also.
This bug broke our integration autotest suite running with Playwright.
Cannot do a proper repro though. This issue prevent Playwright to close browser window.
Using

"@microsoft/applicationinsights-web": "^3.0.5",

[kbeeveer46]

I should have done this when I created this post but I just downgraded until I got to a version where the issue does not happen. The issue does NOT happen in version 3.0.3. The issue happens in version 3.0.4 and 3.0.5.

When I did my tests I was using App Insights in a custom web part inside SharePoint Online with the latest version of Chrome and checking/unchecking the "Block third party cookies" option under the Third party cookies settings.

[alfeg]

Seems to be duplication of #2195

[kbeeveer46]

Seems to be duplication of #2195

@alfeg Yep, seems to be the same issue. SharePoint Online does a bunch of funky stuff when third party cookies are disabled like doing full page reloads 4-5 times after the initial page load for their authentication. That could be what's triggering it for me. I imagine there are a lot of different scenarios that trigger the bug.

[MSNev]

This does seem to be a side effect of #2195, and as part of this you will need to either downgrade ☹️ or include the useSendBeacon: false in the configuration as we have not scheduled releases for the rest of '23 due to the holidays.

[MSNev]

Tagged as a bug and p1.

Is anyone hitting this when downloading via the CDN? ai.3.min.js or ai.3.gbl.min.js (as these are both v3.0.5), so you can't easily downgrade (but we could roll them back to 3.0.3 if required).

[sayowayah]

Tagged as a bug and p1.

Is anyone hitting this when downloading via the CDN? ai.3.min.js or ai.3.gbl.min.js (as these are both v3.0.5), so you can't easily downgrade (but we could roll them back to 3.0.3 if required).

@MSNev Yep, I seem to be hitting this when using the CDN js file. Any way for me to easily downgrade the js file to 3.0.3?

[MSNev]

@MSNev Nev Wylie FTE Yep, I seem to be hitting this when using the CDN js file. Any way for me to easily downgrade the js file to 3.0.3?

Yes, I was afraid of that.
I've started the process of creating an out of band deployment (which will be called v3.0.6), we have an initial PR to address this which is being dropped into main #2208, but as we already have other code in main we are going to have to create a special release branch -- so it will be a few days before we will be able to publish and then probably next week before we promote as the primary version on the CDN.

To answer your question -- Yes, you can target a specific release from the CDN (as long as we deployed it to the CDN), the details about all of the different formats along with the primary and full versions is documented on the main readme page here

But simplistically, instead of saying ai.3.min.js or ai-3.gbl.min.js, just specify the full version number ai.3.0.3.min.jsorai.3.0.3.gbl.min.js`

From a process perspective, on the day we "publish" a release to the npm we also publish the full version to the CDN (it's now automated), and then we go through a promotion process to effectively "change" the ai.3.min.js (etc) to be the new "promoted" version (simplistically we copy the full version (ai.3.0.3.*) to ai.3.0.* and ai.3.*)

[kbeeveer46]

OP here, this issue appears to be fixed in 3.0.6. I cannot reproduce it when disabling third party cookies like I did before.