addFcmToken (HTTP) creates a new Firestore doc under users on each reinstall, causing many token documents per user

[seesaw404]

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

With Push Notifications enabled and deployed, the Cloud FunctionaddFcmToken(HTTP, v1) receives traffic. Each registration results in a new document under users/{uid}/fcm_tokens with a random document ID, so one user accumulates many token documents over time (e.g. after TestFlight reinstalls or token refresh).

Downstream, only the “first” or an arbitrary token may be used unless the backend explicitly picks the newest document. Push delivery can fail or target the wrong install even though FCM/APNs are configured correctly.

Expected Behavior

FCM token storage should update a single document per user (or one per device with a stable ID), e.g. set/merge on a fixed path like users/{uid}/fcm_tokens/default or users/{uid}/fcm_tokens/{deviceId}, instead of add() with a new auto-ID on every registration.

Alternatively, FlutterFlow should document the intended behavior and provide a supported way to avoid unbounded growth of fcm_tokens subcollections.

Steps to Reproduce

1. Create/use a FlutterFlow project with Firebase and Push Notifications enabled and Deployed (so addFcmToken and related infra exist).
2. Sign in as a user so the app registers FCM and calls token registration (as FlutterFlow does on launch / after permission).
3. In Firestore, open users/{uid}/fcm_tokens and note document IDs.
4. Trigger token registration again (e.g. reinstall the app from TestFlight, or clear app data and open again, or wait for token refresh if applicable).
5. Open users/{uid}/fcm_tokens again and observe additional documents with new random IDs instead of updating the same document.
6. In Google Cloud Console → Cloud Functions, confirm addFcmToken shows repeated invocations corresponding to these registrations.

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

ITEShsmAz4Zgru4E+pfbY+5QhQIgQ0QnU7gnlO1ucx40GJDpPJoIfs/BaUNKQteFTFVMIFH8pEAywt7LvdrAGMIqJU+bc5xZ0JVAVhaVbDqlb6qoCLmKYHMmBdJXJ0CFyLunnhBTBO1oWnBg12atNq3qNleeY8aSfxBlZ7vfcPo=

Visual documentation

i removed the docs in order to get the notifications to work...

Environment

- FlutterFlow version: [e.g. v5.x – from FlutterFlow UI]
- Platform: [Web builder / macOS app – whichever you use]
- Browser name and version: [e.g. Chrome 131]
- Operating system and version: [e.g. macOS 15.x]
- Affected app: **iOS** (TestFlight)

Additional Information

We confirmed FCM + APNs work when targeting the *correct registration token (e.g. Firebase console test). The problem is multiple stored tokens and non-deterministic which doc backend logic reads first.

We mitigated server-side by preferring the newest created_at under fcm_tokens, but the root issue appears to be how addFcmToken writes to Firestore (likely add vs set/merge). Requesting clarification on intended behavior and a supported pattern for one doc per user/device.

[Alezanello]

Hello!

FCM tokens are generated by the client app instance as part of Firebase’s default behavior. This isn’t something modified or controlled by the addFcmToken function.

You can find more details in the official documentation here: https://firebase.google.com/docs/cloud-messaging/manage-tokens#retrieve-and-store-registration-tokens

[seesaw404]

Thank you!!