Malfunction in the API retrieving worklogs

Update timeline

1. investigating Feb 10, 2025, 11:38 PM UTC

   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.

2. investigating Feb 10, 2025, 11:38 PM UTC

   We are continuing to investigate this issue.

3. identified Feb 11, 2025, 11:07 AM UTC

   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.

4. monitoring Feb 11, 2025, 11:41 AM UTC

   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,

5. resolved Feb 12, 2025, 04:34 AM UTC

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