This question already has answers here:
Firebase: when onDisconnect event fire?
(2 answers)
Closed 3 years ago.
I am trying to implement a presence feature in my Firestore app, for orientation I was using the suggested google solution that can be found in the link below (hybrid solution using Firebase Realtime Database and cloud functions):
https://firebase.google.com/docs/firestore/solutions/presence
I was hoping that the .onDisconnect would fire when I lose internet connection however that only happens after about 60seconds. Is that the normal behaviour of that method or did I do something wrong? I would love if that happened much quicker than that. Any firebase people who can explain what happens under the hood here? Couldn't find anything about triggering conditions for Firebase.Database.onDisconnect. Thank you so much.
This is the expected behavior. It takes that amount of time to discern if the connection is actually lost, or instead just temporarily blocked for whatever reason. Basically, 60 seconds is the "timeout" until a read or write on the socket between your client app and the server is expected to complete.
Related
I have an iOS app connected to Firebase Crashlytics. For some crashes the console does not show stack traces (or any other data for that matter), only an error message saying "There was an error loading your session":
This does not happen for all crash events: for some of them, crash data is properly shown. I have tried to get in touch with Firebase support, but no luck so far.
Is anyone experiencing this issue? Any hints about what might be causing it?
Alternatively is there a way to download the raw crash data from Crashlytics?
Firebase tech support has confirmed that the problem is that their backend is having trouble storing the crash data:
what appears to be happening is that the stacktraces for these crashes are too large for Crashlytics to persist to storage. Normally, Crashlytics removes extra threads and manages to store the crash, but if the frames within the threads are too large, we would encounter issues storing the crashes.
Also they say that since the problem is that they did not manage to store the crashes, they cannot provide any way to download the raw crash data either.
They further mention that they are considering implementing ways to increase our size capacity, but they don't have a specific timeline for that, and they consider this a "feature request".
Needless to say I strongly disagree on this last bit, given that:
On iOS it is not really possible to install more than one exception handler / crash reporter
So basically you need to choose WHO you will be sending your crash reports to
If the crash reporting engine then fails to persist your data, then the data is essentially lost
It's difficult to understand how "not losing your data" is considered a feature request rather than a severe bug.
I have found a workaround for this.
If you manually search for the issue title in the issues list and open it from the search tool, the stack trace appears.
This is rather just a straight forward question.
Does Firebase Realtime Database guarantees to follow 'First come first serve' rule when handling requests?
But when there is a write-request, and then instantaneously followed by a read-request, is the read-request will fetch updated data?
When there is a write-read-write sequence of requests, does for sure read-request fetch the data written by first write?
Suppose there is a write-request, which was unable to perform (due to some connection issues). As firebase can work even in offline, that change will be saved locally. Now from somewhere else another write-request was made and it completed successfully. After this, if the first device comes online, does it modify the values(since it arrived latest)? or not(since it was initiated prior to the latest changes)?
There are a lot of questions in your post, and many of them depend on how you implement the functionality. So it's not nearly as straightforward as you may think.
The best I can do is explain a bit of how the database works in the scenarios you mention. If you run into more questions from there, I recommend implementing the use-case and posting back with an MCVE for each specific question.
Writes from a single client are handled in the order in which that client makes them.
But writes from different clients are handled with a last-write-wins logic. If your use-case requires something else, include a client-side timestamp in the write and use security rules to reject writes that are older than the current state.
Firebase synchronizes state to the listeners, and not necessarily all (write) events that led to this state. So it is possible (and fairly common) for listeners to not get all state changes that happened, for example if multiple changes to the same state happened while they were offline.
A read of data on a client that this client itself has changed, will always see the state including its own changes.
Update: After 9 months of back-and-forth emails (over 40 emails), Google has acknowledged that they have found some bugs that may be responsible for high bandwidth usage, but bandwidth usage is still too high. Resolving this issue does no appear to be a priority for Google/Firebase (it took them 1.5 months to respond to the last email). In light of similar complaints such as: https://news.ycombinator.com/item?id=14356409, and many others, across a wide range of teams/developers, hopefully the situation will improve some day.
I'm just starting a Firebase project and have not accessed the database from any client. I have only created a single tiny test key-value pair in the database (using the console), which uses 23 B of data storage. Surprisingly, the console shows that I have used 215.9 KB (including when I was not touching Firebase at all). This number continues to grow every hour even though I am not using Firebase or even refreshing the data tab in the console!
Here is a screenshot of the console bandwidth usage chart:
Firebase console bandwidth usage screenshot
Others appear to be having the same problem, but there has been no response from Firebase/Google. What's going on? Any help would be greatly appreciated.
The usage chart takes time to update. You may be seeing bandwidth from a few minutes to a few hours ago.
Also, this reminds me of the old Google Analytics referrer issue, the default rules for firebase look something like this:
.read = true;
.write if auth != null;
This means that anyone anywhere can read from your database and that anyone authenticated(even anonymously) can write to it. It is possible since it is a noSQL database with json support that it is probably just crawlers which are the equivalent of Google Analytics referral spam.
Is there a way to check the status of the Nest servers?
They appear to be down right now. Currently I'm checking by firing a GET request to:
https://developer-api.nest.com/?auth=...
Which works fine, I can just set a timeout and check the status codes.
I'm using the Firebase API (OS X) and I'm wondering, maybe there is a better way I can check? I don't see anything in their API. observeEventType:withBlock:withCancelBlock: never gets called.
Also, will the firebase observeEventType: block automatically start being called once the servers are back?
After 2 days the block appears to be lifted. I tried contacting Nest 2 days ago and I never got a reply. Perhaps they lifted the block and didn't reply, or it happened automatically.
I believe I was blocked because I was using my real account, with a real device. And obviously because I was in development I was logging in/out and changing values a lot.
I didn't realise until after the block you can create virtual devices (on a new account). More information here: https://developer.nest.com/documentation/cloud/chrome-extension
Moral of the story: use virtual devices!
I have an app that uses firebase for its data. Everything worked fine last night and now this morning. I am having trouble writing to a particular part of the dataset. Returning this
WebSocket is closed before the connection is established Error. I have no real connection issues and am able to read/write from other locations. https://www.firebase.com/test.html returns all looks good. Some help/direction here would be appreciated.
Ok. I will answer this in case others encounter. It turns out the firebase url which is being referenced is created dynamically and instead of a fully qualified url it was being sent "http://myapp.firebaseio.comundefined". I had disabled the initialization because I was debugging a webkit issue. Anyway. You may get this misleading error as a result of a malformed url.
-Eric