Had a question with regards to the snowplow Objective-C SDK (we use this SDK by mapping the values through to swift, not sure if that’s relevant). We are currently tracking data from the IOS app with this SDK, but are finding that the sessioncontext (the mechanism that tracks whether or not a new sessionid should be initialized) is acting strange. Apparently, new session id’s and indices are initialized way sooner than what we setup (within a couple of seconds). As far as we know this has been the case since we started, but since we’re now actively using the data this issue came up.
Example data from the collector_tstamp and part of contexts (because there’s a lot in there):
- collector_tstamp: 2019-12-16 13:53:40
- part of contexts: …“sessionId”:“bfc1ede0-1b28-4bc5-a574-98f716e0ff99”,“userId”:“41cf4536-3a99-428d-9c14-2f1e929c53a1”,“sessionIndex”:303,…
- collector_tstamp: 2019-12-16 13:53:41
- part of contexts: …“sessionId”:“38b5b260-da97-49a9-b1ae-9c98c18daed0”,“userId”:“41cf4536-3a99-428d-9c14-2f1e929c53a1”,“sessionIndex”:306…
We doublechecked if other timestamps could say something different but they all say roughly the same.
We’ve set the fore- and background timeout to both 1800 seconds, to make sure timeout’s only happen after 30 minutes of inactivity, but this does not seem to have large effect. We also tried changing it to 18000 to doublecheck if we were dealing with milliseconds, but nothing significantly changed here.
I’m currently working on defining the sessions from SQL side as temporary fix, but ideally we would not have to do this. Does anyone have a suggestion we can try from the app code’s perspective?
Swift 5, iOS 13.2.3, Snowplow 1.1.5 ( we updated from 1.0.4 to see if we could fix the issue with that, but that proved to not have any effect)