I'm trying to do some activity analysis via the timeline API request /2.2/users/${userid}/timeline
I'm running into issues distinguishing user_timeline results from each other occasionally. It's possible to get results for the same entity in the same second. In one particular case, revisions of an answer occur in the same second. Each revision does have a different detail but I don't believe detail is guaranteed to be different?
{
post_id: 49161331,
user_id: 1318694,
timeline_type: 'answered',
post_type: 'answer',
creation_date: 1520457382,
title: 'Node/Docker is node-sass not finding installed bindings (via Webpack)',
id: 'tML3WkieXGG/Jt62SxE+ae11fCs='
},
{
post_id: 49161331,
user_id: 1318694,
timeline_type: 'revision',
post_type: 'answer',
creation_date: 1520457382,
detail: 'notes about deletion',
title: 'Node/Docker is node-sass not finding installed bindings (via Webpack)',
id: 'JjOrzxAEbmnaerDxwYdmhLRISRE='
},
{
post_id: 49161331,
user_id: 1318694,
timeline_type: 'revision',
post_type: 'answer',
creation_date: 1520457382,
detail: 'notes about deletion + intro',
title: 'Node/Docker is node-sass not finding installed bindings (via Webpack)',
id: 'R7KDZ/kmqJDpnYn5AzBnvGUE6V0='
},
At the moment I'm relying on a shasum of the object (seen as id) but if detail doesn't change then that won't work any more.
The second problem stems from the order of the timeline and paging. If new activity is added to the timeline, the entry is added to the beginning of items and the items on the page boundaries are shifted. If this happens during querying, I can't easily identify if the shifted entry is in fact a duplicate that has shifted from the previous page, or just an entry that has similar data.
If the results could be sorted the opposite way (by time, from oldest to newest) then paging wouldn't be an issue as items wouldn't be able to shift pages, new activity would be appended to the end and pages remain consistent.
A unique ID would also suffice but I'm assuming this is some kind of view into data so there no id to attach.
pagesizethat includes enough leeway either side of theuser_timelineitem in question to ensure it's in the middle. Then search for the possible dupe to confirm the entry before is/isn't a dupe.totalavailable in the .wrapper if you apply a filter. That should make it easier to detect shifts while querying.totalis 2344 but I am getting 2830 results from the API, 29 pages with the last page having 30???totalof 2344 doesn't line up with any combination of the item types I can tell:{ commented: 1262, reviewed: 112, answered: 654, revision: 684, badge: 99, asked: 4, accepted: 3, suggested: 12 }