Scream for Joy

Remote work sounds great until you’re stuck on a single problem for three straight days, questioning your life choices.

This was me, battling Google Cloud Firestore integration. Skipping workouts, canceling plans, and staring at the same error messages until my eyes burned. But finally, finally, I cracked it. Here’s what happened.

Technical challenge

When I first set up Firestore, it defaulted to Datastore Mode, I learned doesn’t work with mobile apps. Great. So I created a new Firestore in Native Mode, gave it a custom name (not the default (default)), and thought I was golden.

Spoiler: I was not.

The Debugging Nightmare

No matter what I tried—flutterfire configure, restarting, rewriting code—Firestore kept throwing this error:

W/Firestore(19834): (25.1.2) [WriteStream]: Stream closed with status: Status{code=NOT_FOUND, description=The database (default) does not exist for project

The Breakthrough

Then it hit me, what if Firebase was still looking for the default database, even though I named mine something else?

I modified my Firestore initialization “explicitly” (for privacy purposes) as to my custom database:

FirebaseFirestore firestore = FirebaseFirestore.instanceFor(
  app: Firebase.app(),
  databaseId: '###', // My actual Firestore name
);

And just like that… it worked.

The Aftermath

Three days. Three. Days. Of debugging, canceled plans, and sheer frustration, all because of a tiny, undocumented issues.

But hey, at least now I know:
✅ Firestore in Native Mode ≠ Automatic mobile compatibility
✅ Custom database names require to call databaseId ✅ Persistence pays off

Moral of the story? Sometimes the solution is one obscure line of code away, even if it takes three days of suffering to find it.