The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
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.
duskolicanin.com
Build a Recoverable Firebase Account Deletion Flow
Fix Firebase account deletion that fails with requires-recent-login or leaves orphaned data: reauthenticate, then let a server job delete data before the user.
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!
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
Cancelling a purchase and failing a purchase reach your Flutter code the same way, as a PlatformException. That is how a paywall ends up showing a red error to someone who simply changed their mind on the store sheet.
PurchasesErrorHelper.getErrorCode is what distinguishes them, and two outcomes are not enough. A single call to Purchases.purchase can end five ways: cancelled, pending, completed, failed and unresolved. Pending is the one that catches people out. A parent still has to approve the purchase, or a slow payment method has to settle, and RevenueCat grants no entitlement until the store confirms it.
Which means the paywall screen should not be what decides access. A pending purchase can complete after the paywall closes or after the app has been killed, and RevenueCat does not push that change to the device. Keep a CustomerInfo listener in an object that lives as long as the app, and have every paid feature read the entitlement from it rather than from whatever the purchase call returned.
https://www.duskolicanin.com/blog/flutter-subscription-pending-cancelled-purchase
duskolicanin.com
Handle Pending and Cancelled Flutter Purchases
Handle RevenueCat cancelled and pending purchases in Flutter: map error codes to paywall states and unlock only from an active entitlement listener.
This is such a real pain point! So many paywalls break exactly here - treating a user cancellation as a crash. Thanks for pointing out PurchasesErrorHelper.getErrorCode to distinguish it. Handling cancelled vs pending correctly is crucial for UX, no one wants a red error for changing their mind. Saving this!
Finova is a mobile banking and personal finance app I built end to end in FlutterFlow, shipping to iOS and Android from a single project. Users can check their balance, send money in seconds and see where every dollar goes. It is a concept project that shows my full workflow, from design to build.
How I built it in FlutterFlow:
1. UI: Home, Send Money and Insights are built with responsive widgets (Column, Row, Stack, ListView) and a shared theme for colours, typography and spacing, so every screen feels consistent.
2. Components: Balance card, quick-action buttons, transaction rows, number pad and bottom navigation are reusable components with parameters.
3. Authentication: Firebase Authentication handles secure sign-up and login.
4. Database: Firestore stores accounts, transactions and budgets, and query-driven ListViews power recent activity and spending breakdowns.
5. Send flow: Action Flows and App State validate the amount and recipient, record the transfer and show a confirmation.
6. Insights: Custom charts turn transaction data into spending categories and a monthly budget bar.
7. Payments: Stripe can be connected for real payment processing.
The result is a fast, polished fintech app with a clean deep navy and blue design, ready for real-device testing and store release.
AI Application DevelopmentDesktop Apps DevelopmentFlutterflow Development FirebaseFirebase AuthenticationFlutterFlow
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.
duskolicanin.com
Keep Flutter Push Tokens Correct Across Devices
Fix Flutter push notifications that miss a second device or follow the previous user: store one FCM installation ID per device and prune unregistered IDs.
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. 👏