Firebase multi path query takes long to response - firebase

I am using firebase realtime database and I have a multi path firebase update query that I was using for a while, however for last couple of days the callback never fires and other firebase database requests are blocked as well until this one fires. Callback takes incredibly longer to fire than it should or it used to. And most interestingly this issue does happen on Windows environment only.
let updateObj = {}
updateObj[`transcripts/${uid}/${itemId}/currentState`] = currentState
updateObj[`lists/${uid}/${itemId}/edited`] = firebase.database.ServerValue.TIMESTAMP
updateObj[`lists/${uid}/${itemId}/filename`] = title
db.ref().update(updateObj, function(error){
//handle error
}
I thought it could possibly be because another reference is initialized at the same path later on but callback sometimes hangs even before that.
updateObj[`transcripts/${uid}/${itemId}/currentState`] = currentState
variable currentstate above has a somewhat of a big array node inside so I also think the array might be the issue considering they don't really work that efficiently with firebase realtime database.
Commenting this out solves all the problem but I am still clueless how this suddenly started to break firebase realtime database for me.

Related

Unity Firebase RTDB doesn't work after building

Unity version 2020.3.22f1,
Firebase SDK 9.0.0 dotnet4
I've imported both the analytics and real-time database SDK.
The Analytics works perfectly fine.
Regarding the database, building an Android app bundle and uploading to internal test or building an APK and uploading directly to my phone or building for IOS and uploading to test-flight all 3 results with an error.
This is how I initialize Firebase-
FirebaseApp.CheckAndFixDependenciesAsync().ContinueWithOnMainThread(task => {
//init analytics
FirebaseAnalytics.SetAnalyticsCollectionEnabled(true);
DatabaseReference = FirebaseDatabase.DefaultInstance.RootReference;
Debug.Log(JsonConvert.SerializeObject(DatabaseReference.Database.App.Options));
});
This is how I use the database (increment the win field of a specific level) -
DatabaseReference.Child("Levels").Child($"Level{levelNum}").Child("Wins").RunTransaction((mutableData) =>
{
mutableData.Value = Int32.Parse(mutableData.Value.ToString()) + 1;
return TransactionResult.Success(mutableData);
});
Referring to the log above in the DatabaseRefrence initialization, in the editor, I can see all the configuration properties - databaseUrl,apikey,AppId, etc...
Debugging the APK on my phone the Options property only includes the databaseUrl.
And when trying to perform a transaction to the database an error is being thrown -
W/Unity: Exception in transaction delegate, aborting transaction
System.NullReferenceException: Object reference not set to an instance of an object.
at ....(Firebase.Database.MutableData mutableData)
Things I've tried so far-
I've added the SHA1/SHA256 of both my debug Keystore and googles console App integrity
I've checked and the XML files are being generated with all the details successfully at the streamingAssets folder and at Assets\Plugins\Android\FirebaseApp.androidlib\res\values\google-services.xml
I've tried Initializing the Firebase app manually as mentioned here - https://stackoverflow.com/a/66874818/7210967, doing that indeed results with the debug.log above to include all the Options parameters but the same error occurs as if it doesn't actually use it. (I've tried doing that both with the configuration files in place and removed them completely).
I've tried overriding the default app instance Options.
I've read some posts saying that Proguard obfuscation might cause errors with firebase? couldn't find anything related to Unity.
If anyone has any ideas, please share! ty
Transactions in Firebase Realtime Database work a bit differently than you might expect, as they immediately invoke you handler with the client's guess about the current value of the node, which in general is going to be null.
So when you call mutableData.Value in your code, you get back null and you then call ToString() on it, which leads to the error you get. To solve this, first check whether the mutableData.Value is null before invoking methods on it.
int current = mutableData.Value is null ? 0 : Int32.Parse(mutableData.Value.ToString());
mutableData.Value = current + 1;
return TransactionResult.Success(mutableData);
Syntax errors are possible in the above, as it's been a while since I wrote C#.
A transaction send both the SDKs guess and your new value based on that guess to the server, which then does a compare-and-set operation. If the guess doesn't match the actual value in the database, the server rejects the write with the current value, which the client then uses to call your transaction handler again with an updated current guess.

Firebase: First write is slow

Currently developing a hybrid mobile app using ionic. When the app starts up, and a user writes to the Realtime Database for the first time, it's always delayed by around 10 or more seconds. But any subsequent writes are almost instantaneous (less than 1 second).
My calculation of delay is based on watching the database in the Firebase console.
Is this a known issue, or maybe I am doing something wrong. Please share your views.
EDIT:
The write is happening via Firebase Cloud Function.
This is the call to the Firebase Cloud function
this.http.post(url+"/favouritesAndNotes", obj, this.httpOptions)
.subscribe((data) => {
console.log(data);
},(error)=>{
console.log(error);
});
This is the actual function
app.post('/favouritesAndNotes', (request, response) => {
var db = admin.database().ref("users/" + request.body.uid);
var favourites = request.body.favourites;
var notes = request.body.notes;
if(favourites!==undefined){
db.child("favourites/").set(favourites);
}
if(notes!==undefined){
db.child("notes/").set(notes);
}
console.log("Write successfull");
response.status(200).end();
});
The first time you interact with the Firebase Database in a client instance, the client/SDK has to do quite some things:
If you're using authentication, it needs to check if the token that it has is still valid, and if not refresh it.
It needs to find the server that the database is currently hosted on.
It needs to establish a web socket connection.
Each of these may take multiple round trips, so even if you're a few hundred ms from the servers, it adds up.
Subsequent operations from the same client don't have to perform these steps, so are going to be much faster.
If you want to see what's actually happening, I recommend checking the Network tab of your browser. For the realtime database specifically, I recommend checking the WS/Web Socket panel of the Network tab, where you can see the actual data frames.

Firebase Cloud Functions for Firestore trigger doens't work unless redeploy

I have this function to handle contact submissions. It get's triggered onCreate for a document in a collection in Firestore. The function is using the new v1+ syntax and it works every time I deploy the function to Firebase.
I'm getting a weird behavior where the function works fine for a couple of weeks and then it stops working. I can see new documents being created on the collection but the function doesn't gets triggered.
There are no logs or errors in the console for the function. The trigger for the function in the dashboard clearly states:
document.create
/someCollection/{documentId}
Once I redeploy the same function (no change is done to the code) the function start triggering as normal.
Have anyone seen this behavior?
Solution: redeploy your functions and the problem should not happen ever again.
According to the Firebase documentation:
Max inactivity time for background functions = 30 days
The maximum amount of time that a background function can be kept without any invocation. Functions that are not invoked even once during this time may enter a state in which new events will not trigger them anymore. If this happens, such functions have to be redeployed to start working again. Note: This inactive state is not reflected in the UI, CLI, or API in any way.
However, a Firebase team member commented in another SO thread:
This limitation was removed as of today. You will have to redeploy your Cloud Functions one final time, but after that they shouldn't be auto-removed after 30 days anymore.

Using Firestore from a JobIntentService: Failed to gain exclusive lock to the Firestore client's offline persistence

Whenever I exit the app while I have an alarm set and the alarm goes off while the app is "DEAD" I get an Exception while trying to update a field in Firestore.
The code works when the app is running in the foreground so I really have no clue of what is going on. Either way, here is the code for 2 functions which get called from the JobIntentService which is in turn created from a BroadcastReceiver:
private val firestoreInstance: FirebaseFirestore by lazy { FirebaseFirestore.getInstance() }
fun updateTaskCompletedSessions(taskDocRefPath: String, completedSessions: Int){
val taskDocRef = firestoreInstance.document(taskDocRefPath)
taskDocRef.get().addOnSuccessListener { documentSnapshot ->
documentSnapshot.reference
.update(mapOf("completedSessions" to completedSessions))
}
}
fun updateTaskSessionProgress(taskDocRefPath: String, sessionProgress: String){
val taskDocRef = firestoreInstance.document(taskDocRefPath)
taskDocRef.get().addOnSuccessListener { documentSnapshot ->
documentSnapshot.reference
.update(mapOf("sessionProgress" to sessionProgress))
}
}
The full error goes as follows:
Failed to gain exclusive lock to the Firestore client's offline persistence.
This generally means you are using Firestore from multiple processes in your app. Keep in mind that multi-process Android apps execute the code in your Application class in all processes, so you may need to avoid initializing Firestore in your Application class. If you are intentionally using Firestore from multiple processes, you can only enable offline persistence (i.e. call setPersistenceEnabled(true)) in one of them.
I will appreciate any help. Thank you!
I'm happy to announce that I found a solution! I was using two consequently firing JobIntentServices - one for completedSessions, the other for sessionProgress. (Bad design, I know...)
When I played around with it and made just ONE JobIntentService to call both of these functions, the exception is gone which makes perfect sense.

authWithCustomToken not firing callback

When a user registers on my system, I create the user internally, and then allow the user to register with Firebase using the firebase client lib. This generates a session token for the user. Later, when a user starts the app again, the app automatically logs the user in like this:
ref.authWithCustomToken(sessionToken, function(error, authData) {...
debugger
I have verified that the sessionToken is available when the function is executed, but debugger is never reached, and no error is ever emitted.
Any help is appreciated!
I know it's a bit late, but I experienced a similar problem and it had me scratching my head for a while, so just in case it helps somebody else, here's what I found.
If I run authWithCustomToken with a token generated with one uid (uid1) and then run it again on the same ref with a different uid (uid2), the callback doesn't get fired the second time around.
In my case, I had declared the same ref in different modules that were used in the same node process and was trying to authenticate them with different uids. Although I had declared the ref twice, Firebase still saw it as the same ref because it was in the same process and referred to the same Firebase location. By declaring and authorising the ref in a parent module, I was then able to use onAuth in the child modules and the onAuth callbacks all fired as expected.
I had a similar problem with iOS, authWithCustomToken callback was never called right after install.
All consecutive launches worked fine.
My findings might be related so I thought I share them.
Problem was I called
func applicationWillResignActive(application: UIApplication) {
Firebase.goOffline()
}
func applicationWillEnterForeground(application: UIApplication) {
Firebase.goOnline()
}
in AppDelegate. Turns out if you call Firebase.goOnline() without logging in first it messes up the callback. Once I removed those two lines everything worked fine.

Resources