How to figure out if firestore security rule failed when client comes back online and pending write completes?

Viewed 494

In my Android app I am writing data to firestore which is being validated with the help of security rules. Since writes work offline too, my (invalid) write task will return success if device is offline. But when the device comes online, the security rule will block the write and the data will disappear from the client. Is there a way for me to know that the write failed? Is it possible for a cloud function to be triggered if security rule fails so that I can inform the user that their write failed after going back online?

1 Answers

When you say "my (invalid) write task will return success if device is offline", this is not exactly how it works. When you write a document to Firestore the SDK will only confirm the write if the app is online and the server confirms that it's written. When you perform a write, the API is going to give you some sort of handle into that operation (Android Task, JavaScript promise) will be completed or resolved when that write actually finishes.

If you are offline, you'll never know for sure if the write was going to work, but the written document will still show up in queries. If you want to know if that document finally finished its write, you'll have to request metadata for that document, and check if that document has an outstanding pending write. For example, on Android, use hasPendingWrites() to find out if the document you have in hand was written.

The SDK doesn't provide you with a way of knowing when your documents sync after it's cold booted. But you can take matters into your own hands by remembering all the paths of the documents that are important to track, persist them locally, then load those paths on cold boot to check for success. You'd add listeners to those documents and check:

  1. If the document doesn't exist, that means the write was rejected before you attached the listener.
  2. If the document exists and hasPendingWrites(), that means the sync is still waiting to happen.
  3. If the document exists without pending writes, it got synchronized successfully.

This strategy only works for adding new documents. For updating documents it's more difficult because a document without pending write may just be an old version of the document before the update sync failed. So you'd need to put some other field in the update that indicates if the update succeeded.

Related