Malfunction in the API retrieving worklogs

The incident has been resolved. We got the confirmation from end users that the results are now consistent

The issue has been identified. The new Jira Search API returns a maximum of 20 worklogs, causing the Timesheet app to loop when this limit is exceeded, as explained yesterday during the meeting. We discovered that the Jira API sometimes sends duplicate or missing entries due to how the data is sorted—once by the worklog's start date and once by its creation date. So the first 20 worklogs are sent by JIRA by started date. Then the following 20 to 5000 are sent based on the creation date . So depending on this , we can have missing or duplicate entries.

There is no reason that Jira sends two different orders like that. But we were able to implement a workaround to re-ask again Jira for all worklogs from 0 to 4999 and then 5000 - 9999. Instead of 0-19 then 20-4999 etc…

We have already published the fix. Meanwhile, we are raising a ticket to Atlassian to get the explanation why the results are not ordred the same way.

Best regards,

The issue has been identified. The new Jira Search API returns a maximum of 20 worklogs, causing the Timesheet app to loop when this limit is exceeded. We discovered that the Jira API sometimes sends duplicate or missing entries due to how the data is sorted—once by the worklog's start date and once by its creation date. To resolve this, we are adding a processing step to collect all worklogs and ensure they are unique. We are testing the fix and will roll it out in the next few hours.

We are continuing to investigate this issue.

We are noticing malfunctions with the API retrieving worklogs. Some worklogs may be duplicated or missing from the results. This impact only third party addons and not JIRA itself, so you may continue logging your time as usual. But calendars and reports may be inconsistent
We are currently investigating this issue.