Is throwing an error a valid way to undo/stop a Firebase transaction?
For a simple example, if I was to:
create a user profile in Firestore (not auth)
then create that user in auth and if it fails for some reason, can I throw an error in the transaction to undo the user profile creation in my system?
Basically, my question is: does throwing an error in a Firestore transaction cause the transaction to revert Firestore documents to their previous state?
Related
I have a step in my new user flow where a user is registered with Firebase auth, and then a record is written to Firestore.
Is there a straightforward way to put both the user registration and the firebase write into a transaction, so if either one fails, they both fail?
Is there a straightforward way to put both the user registration and the firebase write into a transaction, so if either one fails, they both fail?
There are no Firebase products that support cross-product transactional operations. You'll have to nest both calls and always handle the errors. So do the authentication, and then write the data to Firestore or the Realtime Database.
A more convenient way of handling this situation would be to trigger a Cloud Functions in response to the creation of a Firebase user account. In this way, you will only need to handle a single operation on the client.
When the device is offline, the app stores any Firestore changes locally and update them when the internet connection is back. Is there a way to check in the app if the local changes finished uploading Firestore?
There's no API to get a list of the pending writes, nor is there a flag that signals whether there are pending writes. But there are a few things you can do:
For a specific write, you can attach a completion listener to detect when it has completed. When the Future that the write resolves, the write has been committed on the server.
When you're getting a DocumentSnapshot, you can check the hasPendingWrites property in its metadata to see whether the snapshot has pending changes.
How to disable firebase logging or change the loglevel to min in flutter?
example of logs
[FirebaseAuth: ] getGoogleApiForMethod() returned Gms: com.google.firebase.auth.api.internal.zzaq#7862a17
D/FirebaseAuth( 6895): Notifying id token listeners about user ( Wr5ZryMbjqezcexb2a1KWt0W05C3 ).
W/Firestore( 6895): (21.3.0) [FirestoreCallCredentials]: Failed to get token: com.google.firebase.firestore.FirebaseFirestoreException: getToken aborted due to token change.
I don't think there's a way to change the log level directly from your Flutter code.
But you can open the native runner app for Android, and change the log level there.
For example, for Firestore you'd call setLoggingEnabled, as also shown here: How to set log level for Firestore?
I'm actually not sure if the logging from Firebase Authentication can be disabled, but that should typically be a lot less (mostly on app startup, and then every hour when it refreshes its ID token).
Then when you rebuild the Android app, it will use the new settings, and you can continue writing the rest of your code in Flutter.
I've been having some problems with the "reauthenticateWithCredential" method.
I need to be able to delete a user from my application and erase some database nodes with user's data.
The problem is, whenever I call "reauthenticateWithCredential" and receive a positive promise, all future attempts to access my firebase database are simply ignored...no logs or permission errors are shown on the browser console.
I've tried signing the user again, calling other functions outside of the reauth function, restarting Firebase after the reauth but none of these worked.
I like to use firebase functions to test firebase rules I defined.
I would like to read/write to realtime database as an existing user to test if the rules work as expected.
I read in getting started page, I can write to realtime database as admin as follow:
admin.database().ref('/messages').push({original: 'some text'});
How can I do the same as a user I have created in firebase instead of as admin?
I believe when you get the Delta Snapshot from the triggered event that the current state of that snapshot is tied to the user. Since the Firebase team is providing you with the server-less environment, they attach the admin as well since it's in a secure location.
So just grabbing the ref from the current snapshot, should give you the ability to test the database rules. Just to clarify, I am talking about the snapshot.ref, and not the snapshot.adminRef.
Here is the reference from their documentation:
Returns a Reference to the Database location where the triggering write occurred. This Reference has the same end-user permissions as the client that did the write. So, if an unauthenticated client did the write, this Reference is unauthenticated. If the client that did the write is authenticated as a certain Firebase Auth user, this Reference is authenticated as that same user.