Store events in queue for offline usage

[rafaellehmkuhl]

Bug description

I have an application where I'm implementing event-tracking with PostHog. This application is mainly used offline, as it's a mission app. Users usually go to the field, use it several times while offline, and eventually go back home and open it again, now online.

I use Sentry for error-tracking, and it stores the events in the IndexedDB. I'm trying PostHog for event-tracking, and initially it seemed to have persistence options in the library, but after testing a little bit and reading the docs, it seems like its only persisting configuration and user-data, but not the events queue.

In #176 it is mentioned the existence of an offline queue, but it seems to be working only during the session, this is, if the user comes back online without closing the application, the events in the queue will be sent, but if not, they will be lost when the user closes the application.

I'm opening as a bug report because it seems like an undesired behavior, since for offline-first apps this means losing most of the events, but I understand it can be considered a feature request. No problem if the maintainers see it in that way and change the tags.

As a workaround I'm going to implement the persistence on my side, as I liked PostHog a lot. If you see an opening for merging the feature in this library, let me know.

How to reproduce

1. Open you application while online
2. Capture an event
3. Go offline
4. Capture a new event
5. Close you application
6. Go online
7. Open your application again
8. The event that was captured while offline will never appear in the PostHog servers

[rafaeelaudibert]

Hey, @rafaellehmkuhl!

I believe we'll end up considering this as a feature request. posthog-js does not attempt to retry any events, it simply ignores them if they can't be sent to the server. I believe this correlated to PostHog/posthog#24258, where people have been asking for offline support.

I can't promise when we'll be working on this, but I do think this is something we should eventually build to support use cases such as yours.

We've talked about this internally, and we'll likely implement it using an IndexedDB-backed queue similar to the one you built in your PR, but with some kind of deduplication built-in.

Note that I could spot a couple of race conditions on your code, where you might submit the same event more than once, so be aware that they might happen in the future :)

[rafaellehmkuhl]

Hey Rafael! Nice to see a brazilian here, specially a chará haha

Thanks for looking at this, and agree that it should be considered a feature.

About the race condition that you mentioned, you're right and I actually saw some after merging the PR. Will make some changes in the code to account for it. Thanks for the feedback :)