Commit graph

2 commits

Author SHA1 Message Date
infinite-persistence
d7e3127e65 Sync: handle fast-actions being reverted
## Repro
1. Follow a channel.
2. When `preference_set` is sent, unfollow the channel.
3. A few seconds later, the final setting reflects (1) instead of (2).

The current sync loop involves doing a final `sync/get` at the end. While not necessary for the scenario above, the code flow covers various cases, so it's still needed for now.

## Approach
Implement an abort mechanism to the sync-loop.

When syncing from the `buildSharedStateMiddleware` loop, generate an ID for each sync session, and only store the latest one. Pass the ID to the completion-callback (and other places as needed), so we can check if our session is still the latest one before executing the callback.

The check for invalidation can also be placed in more places to cut off the sync process earlier, but it's only done for 2 critical places for now.
2021-12-29 10:32:38 -05:00
infinite-persistence
3040b9ea12
Add flow types to Sync. No functional change. 2021-12-23 16:29:46 +08:00