Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reapply pending updates to remote DIM Sync state #10476

Open
bhollis opened this issue May 30, 2024 · 0 comments
Open

Reapply pending updates to remote DIM Sync state #10476

bhollis opened this issue May 30, 2024 · 0 comments
Assignees

Comments

@bhollis
Copy link
Contributor

bhollis commented May 30, 2024

I realized a case where it could appear that DIM Sync is "losing data" (it's not):

  1. User makes a change (like saving a loadout) which goes into the update queue.
  2. We optimistically apply this update (adding the loadout to their loadout list).
  3. DIM Sync is having some issue with the update (DB troubles or whatnot) and can't flush the queue.
  4. We load a fresh profile snapshot from DIM Sync as part of regular refresh.
  5. The new profile wipes out the optimistic update (even though it doesn't wipe out the update queue).
  6. The changes appear to be "lost" since they no longer are applied to the local state.
  7. Eventually the update queue is applied to DIM Sync when it has recovered.
  8. The next profile load after the queue has flushed shows the saved updates.

Steps 7 and 8 may not happen if the user panics and wipes their local state (the update queue is persisted to IDB otherwise).

Three possible solutions:

  1. Reject new DIM Sync profile loads while the update queue has things in it. This is simple but could cause new info from other devices not to show up, and unlucky timing could cause profile application to be delayed indefinitely.
  2. Every time we load the DIM Sync profile, re-apply the optimistic updates for all items in the queue. We might even find that some updates are now no-ops. This is the best solution!
  3. When we switch to StatelyDB, which has a Sync method, we won't be reloading the whole profile every time, just the changes, and we can resolve items that are changed on the server in a fine-grained way (future).

When this is addressed, we really ought to fill in some of the missing error messaging for terminally failed updates, including the rollback of local state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant