RealmDB error:: Failed to fetch

[roma-hladilka]

How frequently does the bug occur?

Sometimes

Description

I can see about 1500 - 2000 errors per day with this message on Sentry. We use this release (the last one) Realm Web v1.7.1 Why could it happen?

Stacktrace & log output

{
message: Failed to fetch, 
name: TypeError, 
stack: 
TypeError: Failed to fetch
    at r (https://edge.fullstory.com/s/fs.js:3:12094)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:2900993)
    at f (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96325)
    at Generator._invoke (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96078)
    at Generator.next (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96692)
    at n (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182196)
    at s (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182399)
    at https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182458
    at new Promise (<anonymous>)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182339)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:2901233)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:2944930)
    at f (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96325)
    at Generator._invoke (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96078)
    at Generator.next (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96692)
    at n (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182196)
    at s (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182399)
    at https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182458
    at new Promise (<anonymous>)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182339)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:2945631)
    at e.<anonymous> (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:2944788)
    at f (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96325)
    at Generator._invoke (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96078)
    at Generator.next (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:96692)
    at n (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182196)
    at s (https://wallet.gooddollar.org/static/js/2.d216800a.chunk.js:2:182399)
}

Can you reproduce the bug?

Not yet

Reproduction Steps

No response

Version

1.7.1

What SDK flavour are you using?

Atlas App Services (auth, functions, etc.)

Are you using encryption?

No, not using encryption

Platform OS and version(s)

Mainly android web, but others too (Windows, Linux, Mac...)

Build environment

"react-app-rewired": "^2.1.8", "react": "^17.0.2",

Cocoapods version

No response

[kneth]

@roma-hladilka You mention that you are primarily using Android but also Windows, Linux and Mac. Do you see the error on all platforms or only one of them?

Can you explain which functionality of Atlas App Services you are using? It it all functionality which are failing or only one specific one? I am trying to understand where in the Realm Web code base we need to examine further.

[roma-hladilka]

Hi @kneth! I can see the error on all platforms, and 60% of all users that have it are from Android.

In the app we initialise App and Credentials

this.app = new Realm.App({ id: REALM_APP_ID })
this.credentials = Realm.Credentials.jwt(jwt)

login with credentials this.app.logIn(this.credentials) and use mongoClient for database

const mongodb = app.currentUser.mongoClient('mongodb-atlas')
mongodb.db(_databaseName)

after that we work with some collections from db this.database.collection('some_collection')

I think this is all what we do

[johnsmith-gooddollar]

@kneth it seems the issue is happening inside class DefaultNetworkTransport, in .fetch() call:

return await DefaultNetworkTransport.fetch(url, {
                ...DefaultNetworkTransport.extraFetchOptions,
                signal,
                ...rest,
            });

fetch is set here:

DefaultNetworkTransport.fetch = fetch__default['default'];
DefaultNetworkTransport.AbortController = NodeAbortController__default['default'];

values are taken from polyfills:

var fetch = require('node-fetch');
var NodeAbortController = require('abort-controller');

[johnsmith-gooddollar]

@roma-hladilka could you please check which values returned from the above polyfills imports ?

[kneth]

@roma-hladilka @johnsmith-gooddollar

It the polyfill is not correctly set up, it might explain it for your node.js cases. You mention Android Web, is it Chrome for Android? Is it a CORS issue (see https://stackoverflow.com/questions/69872077/javascript-fetch-not-working-on-mobile-devices)?

[sirpy]

@kneth We are actually using realmjs on both webapp version and native(android/ios) But we are seeing this error only from devices running the webapp either mobile or desktop, it actually doesnt happen on our react-native app

[roma-hladilka]

@kneth Are CORS configured in the package? Maybe there is an issue with it? Could you check if headers are configured right? I found some stackoverflow issues, which a similar to ours maybe they will help https://stackoverflow.com/questions/25727306/request-header-field-access-control-allow-headers-is-not-allowed-by-access-contr https://stackoverflow.com/questions/48728173/how-do-i-fix-cors-issue-in-fetch-api

[kneth]

The error Failed to fetch could indicate that the mobile device is loosing connectivity. Sentry will log the error when connectivity is restored. To understand if sporadic connectivity issues are the cause, it could be interesting to compare your 1500-2000 daily errors to the number of fetches you have.

[johnsmith-gooddollar]

@roma-hladilka @kneth i think it could be closed

[kneth]

@johnsmith-gooddollar @roma-hladilka I am curious how you solve the issue?

[kneth]

I am closing the issue due to no reply back. Please comment and reopen the issue if needed.

[sirpy]

@kneth we mostly added backoff retries and it reduced the amount of issues significantly

[sirpy]

@kneth how can we find out if it might be related to rate limiting on your side?

[kneth]

@sirpy Depending on your support plan, you can reach out to our technical service engineers. They can help you digest the server side logs to understand.

In our documentation you can find examples of billing