Firebase account deletion fails in two ways, and only one of them is visible. The documented one is requires-recent-login, thrown when the sign-in behind the delete call is too old. The quieter one is the order of operations: the app deletes the Auth user first, the cleanup that runs afterwards fails halfway, and no signed-in user is left to retry from. The data stays in your database with no account attached. Make deletion a server-owned job. The app reauthenticates with a provider the account actually has, then calls one callable function. That function checks token freshness itself, because the Admin SDK can delete any user without a recent sign-in, and records the request in a transaction so a second tap returns the current status instead of starting another job. Then delete application data first and the Auth user last. Every step has to tolerate a rerun. While the identity exists, a failed job is one the user can sign in and retry. Once it is gone, nothing can.

https://www.duskolicanin.com/blog/flutter-firebase-account-deletion-reauthentication

Super insightful Dusko! 🔥 The "LOGIN DELETED. DATA LEFT BEHIND." visual hits hard.

That quieter failure mode with order of operations is something so many devs miss - deleting Auth user first before cleanup is a classic trap. Thanks for breaking this down, definitely checking your blog!

A push notification model usually breaks in one of two ways: a second phone stops receiving anything, or notifications keep arriving for the account that just signed out. Both come from storing one push address per user. Store one row per app installation instead, with the user ID as a field, and someone with a phone and a tablet has two rows that a single query returns.

The sign-out half has an ordering trap. Delete the installation row while the user is still signed in, then call signOut. A security rule that compares the row owner to the signed-in user refuses the delete once there is no user left to compare against, and the device keeps pointing at the previous account.

The full write-up covers the Firestore rules, the Flutter registration listener, a server cleanup that handles both unregistered error codes, and an acceptance sequence to run on two test installations.

Great technical breakdown! Handling multi-device FCM tokens and secure sign-out correctly is essential for reliable push notifications. I appreciate the focus on both architecture and real-world edge cases. 👏