Tracking currently fails when a negative value is sent. As a negative value shoud not occur at all, I think it should be fine to simply ignore them.
@sgiehl is the negative value provided by the browser? what does a negative value mean in this case when the browser does that? If this negative value is set by the user then we would maybe rather want to throw an exception.
At least this successfully works around the issue. But I agree that it might be worth having a look at why these values even can be negative. I compared the visit IDs of the error log and visitors log and found:
2x iOS Safari 14
5x MacOS Safari 14
ahh one time Firefox mobile on iOS 14
... and so on...
okay the same anonymized user IDs re-appear across multiple visit IDs, I guess it is clear that it is an Apple issue. Not sure if that Firefox was somehow tracked wrong, or if this only shows that Apple users mostly use Safari but it is an Apple issue, not a Safari issue.
In the API let's throw an exception in general and then indeed lets also find out why the browser was sending a negative value and fix that bug and/or not send negative values in the JS
It seems some (older) browser versions have bugs around the performance timings causing some incorrect numbers 🤷
MacOS version were mostly 10.15, a few 10.14, so quite current. However, if you need to to get some more details about the failed visits, let me know, I can also revert the applied changes to get fresh errors.
I actually don't have a Mac. So I can't try to reproduce those problems 🤷
Maybe someone with MacOS/Safari can check for possible reasons...
My wife has one, but is working with it nearly the whole day. Will see if I can get her to do a break an browse our website a bid. Also the browser console output might be interesting 🤔.
btw @sgiehl we also have browserstack to test on any kind of operating system and browser. It can also resolve your local URLs so it's easy to debug.