Code generation: Firestore schema uses instanceFor() with databaseId on long‑term project but instance() on clean project #6434
Description
Can we access your project?
- I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.
Current Behavior
• Current behavior (long‑term project):
- Flutterflow generates the following code within the schema directory at {app}/backend/schema/{schema_item}
- static CollectionReference get collection => FirebaseFirestore.instanceFor(app: Firebase.app(), databaseId: '{prod_db_id}').collection('users');
This code is toxic as the reference to the db is hard-coded, breaking all direct db reads in the app as the pointer is incorrect.
Expected Behavior
Expected behavior:
- On a clean project, Flutterflow generates the following code within the schema directory
- static CollectionReference get collection => FirebaseFirestore.instance.collection('users');
This code is not toxic, and works across db instances.
Steps to Reproduce
Without knowing the logic behind how FF determines whether to generate code in the pattern of instanceFor(databaseId:___), versus .instance
It is impossible for me to reproduce this error. Clarity on the relevant conditionals to the above, may allow me to reproduce this error.
Reproducible from Blank
- The steps to reproduce above start from a blank project.
Bug Report Code (Required)
IT4OiMjfsI52ocMA+KrcYPpajjwRHGY6U4ZMjNV+SQojGJ/NG4gIZfTBXE9uOP25dglmJWaGpHwfzOiKm9z1Kfo5OS6ZR7pi+pZUZwHLUmqmVaqmBc3hPUFUGshbG3ad38O3hwlNBPVqc04G6maEPeTJbD7YQqbaIm0zIfGKWZPXmAfuQ0SLb3kNh1JWeC/v
Visual documentation
Environment
- FlutterFlow version: 6.1.57
- Platform: Desktop
- Browser name and version: N/A
- Operating system and version affected: iOS, 6.1.57Additional Information
This issue makes it impossible for us to test any changes from within the flutterflow desktop app's local run.
After every change, we must download the code, edit the db the schema is pointing to '(default)' from 'hard_coded_prod_db_id', and repeat this process upon every minor change. The same process must be done via github for all deployments. This adds significant friction and time-loss to our testing and deployment flows.
This issue first occurred mid-late last week, following us adding an APN certificate to our prod db, and regenerating config files in-app (for the first time in a while). Unclear if this was the direct cause, or coincidental timing.
What we've tried: Regenerated config files; verified google-services.json and GoogleService-Info.plist are correct; issue persists only in generated backend schema.
It seems possible to me, that FF is interpreting something we have set up in firebase, in a manner we do not intend it to, and thus generating schema file code in a manner toxic to our project.
Our project's FF code is currently fully bricked on all direct backend calls until making the edits described above.
This is possibly resolvable with knowledge as to what logic gates the schema files being generated in one manner versus the other (so we can make the necessary changes to prevent it being generated with this toxic code).
I would describe this as a bug in our case, but entirely possible it is intended behavior generally, that has broken specifically for us due to a quirk in our generalized config setup in firebase.
Clarity as to why the code is generated in the way it is (e.g. the conditionals that need to be met) may be sufficient to resolve in the case of the latter.
Many thanks for your help.