3

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.

  • The work around at the moment seems to be to re-query the API endpoint with another pagesize that includes enough leeway either side of the user_timeline item 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. – Matt Mar 10 '18 at 10:57
  • Aha.. I see there is a total available in the .wrapper if you apply a filter. That should make it easier to detect shifts while querying. – Matt Mar 10 '18 at 10:59
  • The total is 2344 but I am getting 2830 results from the API, 29 pages with the last page having 30??? – Matt Mar 10 '18 at 12:06
  • 2
    Note that those revisions don't actually have the same timestamp, which would be practically impossible anyway. The question timeline API also gives the correct timestamps. This really looks like a bug in the user timeline API, which is returning the creation time of the post instead of the creation time of the revision. – Ilmari Karonen Mar 10 '18 at 12:06
  • Thanks for those links @IlmariKaronen. I had assumed there was a batch somewhere but bug makes more sense. – Matt Mar 10 '18 at 12:17
  • The total of 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 } – Matt Mar 10 '18 at 12:46

You must log in to answer this question.

Browse other questions tagged .