sort task history updates by ExtendedTaskState enum ordinal, not timestamp #1188
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| } | ||
| } | ||
| Collections.sort(updates, comparator); | ||
| SingularityTaskHistoryUpdate lastUpdate = Iterables.getLast(updates); |
There was a problem hiding this comment.
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.
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 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
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
ExtendedTaskSTateordinal 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