Closed dlikhten closed 11 years ago
Since this happens in your own code, eg, you called track. You should probably handle the exception however you think is best. I personally send them to airbrake. But might throw it on a queue in the future.
I think when you are tracking events from the backend you should try to do it asynchronously, and if it is done with a decent queue system you will get retry for free and of-course logs, that should help with Mixpanel down issue or either offline issue.
Also is highly desirable IMO to have an initializer where you setup the gem per environment and also you can even mock the lib if needed.
Since all this solutions are very opinionated I'd prefer to keep the gem without it until feel fully confident some solution is the right way.
Hope this helps.
When there is a communication error with mixpanel (I am testing offline OR mixpanel is down) instead of crashing in the track events, catch the errors, log them, and ignore (or have a callback).
We can add a config flag to preserve old behaviors if someone relies on them.