This repository has been archived by the owner on Aug 18, 2023. It is now read-only.
fix(analytics-process): fix retrieving events from storage #9
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes the case where the storage is overwritten by the first sent events.
The buggy flow:
MixpanelAnalytics
class, that schedules the periodic process (Timer.periodic(...)
) that pushes the events, prior checking if it's the first cycle and pulling events from memory.MixpanelAnalytics
that starts theTimer.periodic
.Timer.periodic
happens. At this point no interaction with the sharedprefs happened, and the events stored in the queues of the driver are empty. Although there are old events stored in memory. The new events gets added to the queue and also stored in memory, overwriting the old ones.Timer.periodic
process executes, memory is checked, but we only have the new events as the old ones were lost.An option is to add some
init()
method that would retrieve the old events from sharedprefs as soon as the driver starts. But as that is an async process that cannot happen in a constructor (could be some sort of static async factory method) it would be a breaking change. So this is an intermediate solution, where we no longer check for any previous stored events in theTimer.periodic
process but in the actual methods where the events are pushed, thus avoiding the overwriting. This solution has the downside that we would only send old events in the scenario where new events are pushed. If no new events are pushed, then any old event would be ever sent.This also updates the lock dependencies to flutter stable 1.22