When I look at the revision history for this answer in the iOS app (version 1.2.2), I see the following - notice the revisions are not shown in the correct order:

enter image description here

  • 2
    Guess the app doesn't yet handle cases of edits occurring in the exact same time, result of "Approve and Edit" of a suggested edit. Poor Brian will have to find a way to detect such cases and handle. ;) Mar 21 '15 at 23:34
  • @ShadowWizard It's a paging API. Gonna have to bump that sorting to the server. Mar 24 '15 at 22:39
  • @Brian so it means a fix is upcoming? :) Mar 24 '15 at 23:04
  • @ShadowWizard soon. I think I see the cause. Mar 25 '15 at 0:54
  • @BrianNickel awesome! Found another bug/issue with revisions so don't plan any vacation just yet. :) Mar 25 '15 at 6:39

This will be fixed in the next API build. (No app update required.)

The list of versions comes into the API as 1, 2, 3 and has to be reversed to get 3, 2, 1. Since the API can return revisions for multiple posts, these get shuffled together using a reverse sort. Unfortunately the reverse sort algorithm is stable and preserves the order of items with the same timestamp giving us 2, 3, 1.

The solution was to reverse the entries before applying the sort so 3 and 2 are in the correct order before sorting (and really no sorting has to be done for one post in this case).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .