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
I realized a case where it could appear that DIM Sync is "losing data" (it's not):
User makes a change (like saving a loadout) which goes into the update queue.
We optimistically apply this update (adding the loadout to their loadout list).
DIM Sync is having some issue with the update (DB troubles or whatnot) and can't flush the queue.
We load a fresh profile snapshot from DIM Sync as part of regular refresh.
The new profile wipes out the optimistic update (even though it doesn't wipe out the update queue).
The changes appear to be "lost" since they no longer are applied to the local state.
Eventually the update queue is applied to DIM Sync when it has recovered.
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:
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.
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!
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.
The text was updated successfully, but these errors were encountered:
I realized a case where it could appear that DIM Sync is "losing data" (it's not):
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:
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.
The text was updated successfully, but these errors were encountered: