Intermittent "Client is offline" rejection from Realtime Database get()

[XuluWarrior]

[REQUIRED] Describe your environment

• Operating System version: AWS Lambda - node-14
• Firebase SDK version: 9.1.1
• Firebase Product: database

[REQUIRED] Describe the problem

Since updating my code to use Firebase 9.x and the new modular API, I am getting intermittent "Client is offline" promise rejections when calling get().
There is a Firebase Google Group that has other users that have experienced the same problem but I can't find a related issue in GitHub, so I thought I would raise one.

I currently running 9.1.1 and so will try upgrading to 9.1.2. I will also enable logging.

Steps to reproduce:

Relevant Code:

initializeApp(config)
database = await getDatabase();
selectionsRef = ref(database, path);
await get(child(selectionsRef, systemName), "value");

Call stack:

Error: Error: Client is offline.
  File "/var/task/node_modules/@firebase/database/dist/index.node.cjs.js", line 11517, col 31, in null.<anonymous>
    return Promise.reject(new Error(err));

[jbalidiong]

Hi @XuluWarrior, thanks for reaching out. I tried replicating, but I wasn't able to reproduce the error. If I can replicate the issue, I can have a better look into it. Please share a minimal, but complete sample of a project that I can run locally.

[XuluWarrior]

Hi @jbalidiong

I don't have consistent reproduction case as I haven't actually seen it running on my local machine. In my case I think it's related to the code being run as a lambda and hence can be frozen and restored in between calls. I can see in my logs that Firebase is often disconnecting and reconnecting but usually it successfully reconnects and there is no error.

Here are the logs before and after the error this morning. Perversely the last log before the error is "Primary connection is healthy" ;)

loggly_disconnections.txt

[schmidt-sebastian]

@IanWyszynski Can you take a look?

[qlereboursBS]

I have the same issue.
I was not able to reproduce it on my local machine, but it's reproducible on a distant environment:

• I'm authenticating to the website, which redirects me to a page loading my user data
• The error doesn't show when loading data
• I can refresh as many times as I want, the error won't show
• If I wait a few minutes or a few hours, when refreshing the page, the error is showing

You can reproduce on the dev environment of my website: dev.traveledmap.com
Since I was able to reproduce it only when logged for the moment, I think you would have to create an account.

[qlereboursBS]

I was just able to reproduce it on my local machine after waiting for a few minutes to refresh the page. However I had the error just once, and then the data successfully loaded (which was not the case on the screen I sent)

[qlereboursBS]

I was able to have kind of a reproduction on a new project, but I think that it's the expected behavior:

• I'm putting a breakpoint in the ready_ method
• I refresh the page that will load some data (get(ref(getDatabase(), 'my-ref'))
• I'm waiting for a few seconds, and the release the breakpoint
• I can see the error in the console.
  I'm not sure if it's the expected behavior because the database request is done just after I release the breakpoint and however the request fails

Maybe it could be related to our issue?

Kazam_screencast_00002.mp4

[qlereboursBS]

I was able to have the issue with my simple example, without breakpoints:

• clone this repository: https://github.com/qlereboursBS/firebase-client-offline-reproduction
• replace the two "TODOs" in the code with your firebase config, and the path to the data you want to fetch
• run yarn && yarn dev to start the project
• Go to localhost:3000 and Hard refresh (ctrl + maj + R on Chrome) the page approximately 10 times, the error should appear randomly (I faced it approximately every 6 times)

@jbalidiong @schmidt-sebastian can you have a look please?
To my mind, this is a high priority bug since it should impact all projects using realtime database

[jbalidiong]

Hi @qlereboursBS, thanks for adding information regarding this issue. I just want to confirm if the repository you've provided contains any code with Firebase? Currently, I'm seeing the default files when created with Next.js. Maybe some files are not uploaded in the repository.

[qlereboursBS]

I'm really sorry, I just realized that the commit and push didn't work, I just pushed it.
You will find the code in pages/_app.js

[qlereboursBS]

Were you able to reproduce @jbalidiong ?
It's a blocking issue for me since it's already on production due to the migration to the v9 and I would like to prevent rolling back before the migration

[jbalidiong]

@qlereboursBS, unfortunately, I wasn't able to replicate it. I also waited for a few minutes before refreshing the page and I didn't encounter the error. Let me check with other engineers and see if they can replicate it on their end.

[qlereboursBS]

I think it may be related to a poor connection. I'm currently in a hotel, the connection is poor, I can access pages but it's very frequent to have this error (almost everytime). When I created the issue, I was at home with a better connection (not the best, but good enough).
What is wierd is that I can have the error for a first request, and get data from another database request just after

[harveylee]

I was having a problem with similar symptoms, using firebase-admin on Windows WSL.

After I enabled logging on Firebase, it turned out that the problem under the hood was that my auth token was being rejected (and fwiw, due to an issue with clock being out of sync: microsoft/WSL#4245).

So I wonder a couple of things:

• Is @qlereboursBS's poor connection leading to a clock/timing issue on auth token refreshes?
• If the issue is due to a rejected auth token (as it was in my case), a more specific error message in the first place would have helped diagnose the problem

[danielo515]

The way I have to reproduce it is to put a breakpoint and just take your time to analyze what is happening.
Since get is supposed to be asynchronous just run it and put the breakpoint in any other area of the app. Then this error occurs.

[JoshuaTyler-GitHub]

I have been able to reliably recreate this issue every time using a basic Firebase Database GET with the Realtime Database.

FirebaseDatabase.getDatabase() .then((database) => { const dbRef = ref(database); get(child(dbRef, path)) .then((snapshot) => { if(snapshot.exists()) resolve(snapshot.val()); else reject(ERROR_UNDEFINED_VALUE); }) .catch((error) => reject(error)); });

In Chrome developer tools, throttle your connection speed to mid or low tier and it will throw "Error: Client is offline."

[sshnavin]

I had similar issue, eventually I figured I had setup the realtime database after I had already generated the Firebase config so it was missing the databaseURL from the config.

Find the Firebase config again from the app it should have it in the config.

Hope this helps.

[Javaworld22]

The issue is the database allows one person at a time. Hence, if a method is reading from a database, this method locks the database from another method reading from the same application

[nugmanoff]

I have been able to reliably recreate this issue every time using a basic Firebase Database GET with the Realtime Database.

FirebaseDatabase.getDatabase() .then((database) => { const dbRef = ref(database); get(child(dbRef, path)) .then((snapshot) => { if(snapshot.exists()) resolve(snapshot.val()); else reject(ERROR_UNDEFINED_VALUE); }) .catch((error) => reject(error)); });

In Chrome developer tools, throttle your connection speed to mid or low tier and it will throw "Error: Client is offline."

I have the same issue, ping me if you figure out something

[ittaboba]

Almost the same for me on v9.0.1 as mentioned by @qlereboursBS

I think it may be related to a poor connection. I'm currently in a hotel, the connection is poor, I can access pages but it's very frequent to have this error (almost every time). When I created the issue, I was at home with a better connection (not the best, but good enough). What is weird is that I can have the error for a first request, and get data from another database request just after

My home wifi is currently at ~5 Mbps in download (don't know why 🤷‍♂️) and I get the error. If I switch to hotspot at ~40 Mbps it works.

This is very annoying and unpredictable behavior. Could you please fix it?

[ittaboba]

In the meantime, I have found a workaround by replacing get calls with this. Hope it helps.

function getData(ref: DatabaseReference): Promise<DataSnapshot> {
    return new Promise((resolve, reject) => {
        function onError(error) {
            reject(error);
        } 

        function onData(snap) {
            resolve(snap);
        }
  
        onValue(ref, onData, onError, { onlyOnce: true });
    });
}

[signorbusi]

We're facing the same problem in our application and it's definitely related to unstable / poor internet connection. This is a major problem for us and very unpredictable. It leads to random crashes of our application.

[rohanx96]

I have been able to reliably recreate this issue every time using a basic Firebase Database GET with the Realtime Database.

FirebaseDatabase.getDatabase() .then((database) => { const dbRef = ref(database); get(child(dbRef, path)) .then((snapshot) => { if(snapshot.exists()) resolve(snapshot.val()); else reject(ERROR_UNDEFINED_VALUE); }) .catch((error) => reject(error)); });

In Chrome developer tools, throttle your connection speed to mid or low tier and it will throw "Error: Client is offline."

Able to consistently reproduce the issue this way for our application too. We have a Firebase fetch when our webpage loads. Throttling network to slow causes the Firebase fetch to fail with error Client is offline. This also happens if multiple (20-25) tabs of our application are opened simultaneously, most likely causing the network bandwidth to be divided and resulting in a slow throttling like scenario.

[marcgallego]

We also have this issue, when connected to rather poor networks and downloading a lot of data from the DB (around 3 MB). It is very problematic for us.

[maneesht]

This should be fixed in the latest version of the SDK with #6340.