0

I have a very straight forward use-case, where a user is able to upload profile pictures of himself and the URL will be saved within the corresponding user's entry in Firestore. Is there a best practice to handle issues regarding atomicity?

Let's say, the user uploads the image and during the process he loses connection or the app crashes, the result will be the file in the Storage but no connection to said file in the user data (if the crash happens exactly after the upload but before the Firestore write).

I considered either using transactions to do so, or implement a Cloud Function trigger, which listens on the storage and handles updating the user profile.

Is there maybe even a way to handle said issue with Firestore rules?

In my concrete app, there are many large images I need to handle, this is why I want to process as much stuff as possible on the client side, but still avoid having huge "dead" images in my database.

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Thomas
  • 2,375
  • 2
  • 17
  • 32

1 Answers1

0

There is no guaranteed way to prevent either orphaned images or dangling references (depending on which write completes first) with Firebase, since there are no transactions across services.

The solution is typically a combination of robust client-side code (in the case of dangling references), and having a script that periodically removes orphaned images. I'd also recommend first testing how bad the problem is, especially if you write the image first.

A workaround to reduce the risk of interruptions could be to use Cloud Functions. The client uploads to Cloud Functions, which then performs both writes. Since Cloud Functions run on a server, they're much less likely to be interrupted.

Also see:

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807