Confirmed users
483
edits
Gaia/Contacts/Data Refactor: Difference between revisions
More on Potential desynchronization
(More on Potential desynchronization) |
|||
| Line 67: | Line 67: | ||
== Data flows == | == Data flows == | ||
=== Initial population of the GCDS === | |||
=== Contact consumer initial fetch === | === Contact consumer initial fetch === | ||
=== Local contact addition === | === Local contact addition === | ||
| Line 98: | Line 99: | ||
# The GCDS wakes up as response to the ''datastore-change-*'' notification. | # The GCDS wakes up as response to the ''datastore-change-*'' notification. | ||
# The GCDS starts syncing with the observed Contact Provider datastore. | # The GCDS starts syncing with the observed Contact Provider datastore. | ||
# The GCDS is killed by the system. | # The GCDS does enough changes on its store to trigger a datastore-change-* notification over the Contact Consumers that are observing the GCDS work. | ||
# We | # The Contact Consumers start syncing with the GCDS. | ||
# The GCDS is killed by the system or the system crashes or we run out of battery or ... | |||
# We have a desynchronization between the Contact Provider and the Contact Consumer that won't be solvable until the next time the GCDS wakes up because of a change on an observed Contact Provider, which again could happen immediately, next month or never. | |||
We need the DataStore API to keep notifying (probably not indefinitely) the observer about the need of synchronization until the sync process is completed. Or at the very least we should make sure that the GCDS can't be killed while doing a synchronization. | |||
* '''Potential performance foot gun''' | * '''Potential performance foot gun''' | ||