faro-web-sdk API calls are going in loop

[snehalk-mdsol]

Facing a faro issue from quite a long now.
Please find below screenshots -

I tried updating faro libraries to the latest version 1.9.0 and added collector URLs in ignoreURLs while initializing a faro instance.
You can check the PR here - https://github.com/mdsol/platform-portal/pull/619/files

Can someone please help.
@codecapitano

[eskirk]

hi @snehalk-mdsol - @codecapitano is on PTO right now, but can you provide some more details regarding the issue you are facing? I am not fully understanding what the problem is.

[codecapitano]

Hi @snehalk-mdsol I can't access the PR you linked.

[codecapitano]

I have a suspicion.
The otlp-http-transport didn't consume the request body so didn't close the connection.
This can cause pending requests, memory leaks and other sorts of problems.

We'll release it soon.

Unfortunately I couldn't reproduce the issue so once released please let us know if the update fixed the problem.

[Shawns2759]

We are seeing this as well. It is a big problem causing lots of failed logs.

[codecapitano]

@Shawns2759 do you use the same setup with the otlp-http-transport?
What is the Faro version your are using?
Can you share you Faro config?
And do you use Faro in a microfrontend with multiple instances running simultaniously?

[Shawns2759]

   "@grafana/faro-react": "^1.5.1",
    "@grafana/faro-web-sdk": "^1.5.1",
    "@grafana/faro-web-tracing": "^1.5.1",

[Shawns2759]

Things are set up very similarly to this PR.

open-sauced/app#3139

[codecapitano]

Architecture is a monolith not a micro frontend right?
Means only a single Faro instance is running?

• Are you using Grafana Cloud or do you send logs to Alloy?
• Did you already update the Faro packages or are you still at 1.5.1?

[Shawns2759]

Our application is a Capacitor application that is serving a nextJs frontend and a a mobile frontend for Android and Apple via Capacitor. We delineate between mobile and web using namespace.

We are using Grafana Cloud.

Faro is still at 1.5.1.

[codecapitano]

Thank you @Shawns2759
Is it possible for you to upgrade Faro to the current version (currently 1.10.x)?

With Faro 1.8.0 we fixed an issue where session timings could drift between the faro receiver and faro itself which lead to
rejected sessions.
It may not be directly related but at least we can exclude that this is causing the issue in your case and then continue the investigation.

Enhancement (@grafana/faro-web-sdk): Auto extend a session if the Faro receiver indicates that a
session is invalid (#591).

[Shawns2759]

Interesting. Yes I will try that.

[Shawns2759]

@codecapitano I updated to 1.10.0 and I am still receiving this error here is what it looks like.

console error: Faro @grafana/faro-web-sdk:transport-fetch Failed sending payload to the receiver { "meta": { "sdk": { "version": "1.10.0" }, "app": { "name": "redacted", "version": "1.0.0", "environment": "production", "namespace": "web" }, "browser": { "name": "redacted", "version": "redacted", "os": "Windows 10", "userAgent": "redacted", "language": "redacted", "mobile": false, "brands": "unknown", "viewportWidth": "1651", "viewportHeight": "801" }, "page": { "url": "redacted" }, "session": { "id": "redacted", "attributes": { "previousSession": "redacted" } } }, "events": [ { "name": "faro.performance.resource", "domain": "browser", "attributes": { "name": "redacted", "duration": "45", "tcpHandshakeTime": "0", "dnsLookupTime": "0", "tlsNegotiationTime": "0", "responseStatus": "202", "redirectTime": "0", "requestTime": "0", "responseTime": "504819", "fetchTime": "45", "serviceWorkerTime": "504774", "decodedBodySize": "53", "encodedBodySize": "53", "cacheHitStatus": "cache", "renderBlockingStatus": "unknown", "protocol": "", "initiatorType": "xmlhttprequest", "faroNavigationId": "redacted, "faroResourceId": "redacted" }, "timestamp": "2024-09-26T18:35:45.594Z" } ] } TypeError: NetworkError when attempting to fetch resource.

[codecapitano]

Can you share a screenshot with the request response information, like request/response headers etc.

[danprat92]

Sharing here in case it is useful for debugging and maybe a possible temporary fix for people facing it. From our testing we came up with the theory that the issue comes from the sheer amount of requests that can be generated by the SDK which apparently causes a race condition somewhere and causes preflight requests to not be performed, hence CORS fails and this error is shown. Attached a picture of how it looks in network tab

To solve it we did 2 things. First was batching with a higher timeout and on top of that increased the default batching item limit to 150 since the default is 50

faro-web-sdk/packages/core/src/config/const.ts

Line 6 in d9d6333

itemLimit: 50,

. This changes causes less requests to be generated so in theory would be less likely of this to happen

Again this is just a theory for now and i don't know if it's the same problem for everyone i'm just starting to monitor the result to see if we still continue seeing this issues. If there's a different issue or way to solve it would be very interested to know 🙏

Note: As an additional note here i'd like to mention that we actually see a very similar behaviour in Datadog which we are migrating away from. Some requests are marked as pending as well

[danprat92]

@codecapitano We have also found similar issue in Sentry and seems to be related to keepalive in fetch getsentry/sentry-javascript#7546 maybe this should be revisited in faro as well. Since we have a fork of faro due to circumstances we did the change and are monitoring to see if we still get errors as the comment above around limits and batching did not fix the error