Hello, thanks for this great tool. I've been using it a while and its made my life significantly easier.
However, the project management team I work with recently discovered that my worklog entries are throwing their reports and epic summaries off.
Repro steps To illustrate, here are some steps to reproduce the problem. We are using Jira Cloud and Tempo. However, the error surfaces in vanilla Jira Cloud reports and exports.
Ticket No,Start Date,Timespent,Comment PATTCONS-845,5/26/2021 8:00,1:00,Test log 1 PATTCONS-845,5/26/2021 9:00,1:25,Test log 2
How it surfaces in vanilla Jira Cloud
EXPECTED: The "Time Spent" field should be 8100 seconds (2.25 hours).
View the project's Time Tracking Report. Reports -> Time Tracking Report -> Configure the report.
RESULT: The "Time Spent" column displays 1.25 hours.
How it surfaces in Tempo
Thanks in advance for looking at this issue.
I updated the description to clarify how the calculation issues surfaces in vanilla Jira Cloud, without Tempo views.
@shridhar-tl, a colleague of mine has been communicating with Jira and Tempo about a bug that seems similar to this one. The cause might be a race condition that Jira doesn't handle. They asked if Tempo could add a "sleep time" between adding work log entries to prevent the bug. This info might help Jira Assistant too.
After reviewing the next steps we raised a new bug describing the behavior. However, after further analyzing we noticed that this is happening when we have worklog entries that are very close to each other, as the examples, I did show previously.
What Jira does in the backend is to calculate the number of logged work and then calculate with the existing entries to show the total on the history table. However, there are some cases where two log entries are coming with ~1-millisecond difference between each other or even 7 milliseconds causing a race condition that prevents the history to effectively add the correct timing. From Jira’s perspective, with the bug added to our product team backlog, we will eventually apply a fix to it. However, would Tempo be able to add a sleep time between the work logs that are sent to Jira? If so, we would recommend Susanne get in touch with our Ecosystem team so they can assist in defining the next steps here.
Hi @heywills , thank you for the info. Yes, your information helps. Currently I am looking for a way to reproduce this issue so that once I fix it, I can test it to ensure if it is working.
But as a result, this is going to slowdown the bulk upload / push of worklog as parallel uploading has to be disabled to solve this issue.
Thanks @shridhar-tl. Let me know if you need any help reproducing this. I understand the impact on import performance. Ironically, being able to use a bulk import again will be much faster than manually uploading one entry at a time.
@shridhar-tl -- thanks so much for this fix (or workaround for the Jira issue). It's making my life much easier.
I hope this issue is resolved and hence closing this issue. Please feel free to reopen if this issue still exists.
Thank you. It is resolved. I have been using the fix since June. It has made my life much easier.