ApplicationInsights reports track to applicationInsights recursively

[muxahuk]

Hey, i have following issue:

my react web application reports calls that are sent to appInsights to appInsights..

what i mean.. my page is loaded and that is being reported to appInsights, after POST call is made to "appinsights.azure.../track" it reports that ".../track" call have been made to appInsights.. so basically recursively calls that call to appInsights was made..

"@microsoft/applicationinsights-react-js": "^3.2.4",
"@microsoft/applicationinsights-web": "^2.7.4",

and it continues until limit of calls is reached.

Not sure what might i have done wrong or there is a bug with these versions of application..

here's my config:

{
        instrumentationKey: process.env.INSTRUMENTATION_KEY,
        connectionString: process.env.CONNECTION_STRING,
        enableAutoRouteTracking: true,
        extensions: [reactPlugin],
        maxBatchInterval: 0,
    }

Not sure why, but sometimes it doesn't go recursively, but once in 10 reloads..

Need some help!

[MSNev]

Internally we tag the reporting calls as internal to stop the endpoints from reporting that an ajax request occurred.

We do this by "tagging" the XHR or fetch request as "Disabled" (added in the following locations) XHR requests; fetch requests and here.

So it sounds like these are failing (we wrap them in try / catch) so the requests are still sent. Are you using XMLHttpRequests or fetch?

[muxahuk]

did not rly understood the question..

my application is using different libraries that automatically report data using they implementation (as far as i can see in debugger - they are using xhr) and also my application is using fetch..

if in config i disableXhr: false then call to /track is done using xhr, if change that to disableXhr: true - it starts using fetch and sends it recursively..

i was able to implement a workaround using config excludeRequestFromAutoTrackingPatterns like so:

excludeRequestFromAutoTrackingPatterns: [
    `http${(process.env.CONNECTION_STRING || 'unknown').split('http')[1]}`,
],

Regarding "disabled" - i was trying to debug and see what happens and in _isDisabledRequest function i don't see that "tag" exists in the xhr variable...

when i try to debug _doFetchSender, at least in callstack i see that it is being used.. i have a code:

arrForEach(objKeys(_headers), function (headerName) {
                    requestHeaders.append(headerName, _headers[headerName]);
                });
// here breakpoint stops
                var init = (_a = {
                        method: "POST",
                        headers: requestHeaders,
                        body: plainTextBatch
                    },
                    _a[DisabledPropertyName] = true // Mark so we don't attempt to track this request
                ,
                    _a);
// here breakpoint doesn't stop
                if (!isAsync) { 
                    init.keepalive = true;
                    // As a sync request (during unload), it is unlikely that we will get a chance to process the response so
                    // just like beacon send assume that the events have been accepted and processed
                    ignoreResponse = true;
                    _syncFetchPayload += batchLength;
                }
                var request = new Request(endPointUrl, init);
// here also doesn't stop and in any next lines till function end..

and after var init = ... it doesn't stop on breakpoints.. i think there is being error encountered, but i don't see it being fired anywhere, so probably there's empty try/catch block or something like that..

[MSNev]

Generally, this code should work... The only issue I could possibly see would be that if your using a polyfill for fetch() which is now implementing the Headers and Blob classes as well.... Or it has some additional restrictions?

[github-actions[bot]]

This Issue will be closed in 30 days. Please remove the "Stale" label or comment to avoid closure with no action.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.