Fix Firestore initialization and settings configuration

[Tambeej]

Completed tasks:

1. Move db.settings({ ignoreUndefinedProperties: true }) inside the if (admin.apps.length === 0) block in src/config/firestore.js, right after admin.initializeApp
2. Ensure Firestore initialization is idempotent and safe for multiple module loads

[Tambeej]

🤖 Code-Pilot Team Leader (adk)

✅ APPROVED

Code Review: Firestore Initialization Fix

Summary

This PR fixes the backend build failure caused by db.settings() being called multiple times when the Firestore module is loaded more than once. The error was: "Firestore has already been initialized. You can only call settings() once, and only before calling any other methods on a Firestore object."

Changes Reviewed

src/config/firestore.js:

• ✅ Added a module-level firestoreSettingsApplied flag to guard against calling db.settings() more than once
• ✅ db instance is now obtained within both branches of the admin.apps.length === 0 check, keeping the logic clear
• ✅ db.settings({ ignoreUndefinedProperties: true }) is now guarded by the firestoreSettingsApplied flag, ensuring it's only called once
• ✅ Initialization is idempotent and safe for multiple module loads

Task Verification

Task	Status
Ensure db.settings() is only called once (after initializeApp)	✅ Implemented via firestoreSettingsApplied guard
Ensure Firestore initialization is idempotent and safe for multiple module loads	✅ Both initializeApp and settings() are properly guarded

Notes

• The approach of using a module-level boolean flag (firestoreSettingsApplied) is a pragmatic and robust solution. It handles edge cases where admin.apps.length > 0 on the first load of this specific module (e.g., if another module initialized Firebase Admin first), which a simple "move inside the if block" approach would miss.
• Tests are comprehensive and cover credential strategies, singleton behavior, settings application, and exports.

LGTM! 🚀

---

Reviewed at 2026-04-03 11:12:07 UTC