-
Notifications
You must be signed in to change notification settings - Fork 187
sort task history updates by ExtendedTaskState enum ordinal, not timestamp #1188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
} | ||
} | ||
Collections.sort(updates, comparator); | ||
SingularityTaskHistoryUpdate lastUpdate = Iterables.getLast(updates); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could consider using Collections.max
here for a slight efficiency gain, also avoids mutating an argument (which is usually dicey code style IMO)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 on Collections.max
, updated
(FYI @wsorenson) |
Another fyi, the original change was introduced by me back in #932 when trying to improve task search speed. The list of updates being returned by a new way of fetching them was an unmodifiable list, so I had resorted to checking timestamps. Should have been checking ordinals instead there |
I've tested this extensively yesterday with over a 100 tasks. The earlier problem did not recur. So looks like this working! Thanks! |
Merging this for |
I found a few cases where it could happen that what we would consider the 'current state' of the task, is not the update that has the latest timestamp:
This PR updates the sort called when fetching task histories to sort by the
ExtendedTaskSTate
ordinal instead of relying only on timestamp. This should give us the correct 'current' state in all cases since the enum is defined in the order we expect statuses to progress during the task lifecycle./cc @tpetr @stevenschlansker @subratbasnet #1187