You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Parse Server deduplicates `_Installation` records when a new install collides with an existing row's `deviceToken`. The`installation` option block configures the dedup behavior.
When `true`, the dedup operation runs with the caller's auth context so ACL and CLP are honored. When `false`, the dedup runs as master and bypasses both. Master and maintenance keys always bypass regardless of this flag.
677
+
678
+
#### `duplicateDeviceTokenAction`
679
+
680
+
What Parse Server does to the conflicting `_Installation` row(s) when a new install's `deviceToken` collides with an existing row.
681
+
682
+
-`'delete'`: destroys the conflicting row.
683
+
-`'update'`: clears the now-conflicting ID field on the conflicting row, preserving custom fields, channels, and history.
684
+
685
+
#### `duplicateDeviceTokenMergePriority`
686
+
687
+
When an existing row holds the new`deviceToken` but has no `installationId`of its own, Parse Server merges the two rows. This option controls which side wins.
688
+
689
+
-`'deviceToken'`: the deviceToken-only row survives; the request's installationId-matched row is the loser.
690
+
- `'installationId'`: the request's installationId-matched row survives; the deviceToken-only orphan is the loser.
* Context mutations leak across requests in `ParseServerRESTController` ([#10291](https://github.com/parse-community/parse-server/issues/10291)) ([60a58ec](https://github.com/parse-community/parse-server/commit/60a58ec11a8bb67aaf217b1e7362b89d742b66da))
0 commit comments