Issue Summary

For a user's public profile Activity Stream gadget, the order of the activities loads in a weird order, missing a few days that will only eventually appear once you click Show More a few times.

Environment

Jira 7.9.0 - Jira 8.3.0

Steps to Reproduce

Go to the public profile of a user and check the Activity Stream. It will appear a few activities of some days. Clicking Show More a few times, it will eventually show activities from day in between the previous dates that were not showing before as well. It doesn't happen to all users.

Please note maxResults=10. Request steps are executed as follows

1. Identify latest changes registered for the user combining the following data:
   1. Get 10 latest issues created by the user (IssueSearch.java:51)
   2. Get 10 latest entries from changegroup table and translate them to issue keys (DefaultChangeHistoryManager.java:393)
   3. Get 10 latest entries from jiraaction table and translate them to issue keys (DefaultChangeHistoryManager.java:398)
   4. Combine results from (1.2) and (1.3) by sorting by latest issue updates and limit the results to 10 (DefaultChangeHistoryManager.java:348)
2. Combine results from (1.4) and (1.1) getting the list of issues that were subject to latest user changes (IssueFinder.java:51)
3. Extract activities for identified issues (JiraStreamsActivityProvider.java:101)

Expected Results

It would show all the activities in chronological order correctly.

Actual Results

It doesn't show the proper activities per day chronologically as expected, hiding a few dates that will only appear after clicking Show More a few times.

Identified bugs:

1. Step (1.4) from the workflow above sorts previously calculated results by latest update date ignoring the author of the changes. The result is then trimmed to 10 issues only.
2. The code in general executes the same action several times as it's first getting the latest activities for a given user from database, then translates the activities into issue keys and then calculates the activities one more time but now based only on previously identified issue keys.

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available