-
Bug
-
Resolution: Fixed
-
Medium
-
3.2.0-OD-08, 3.1.7
NOTE: This bug report is for JIRA Service Desk Server. Using JIRA Service Desk Cloud? See the corresponding bug report.
Basically for SLA events there's a "timed promise" added into a table in the database that tells Service Desk at what point in the future it should fire. The issue is that we're calculating that future value incorrectly, so although the SLA is working fine, automation events that should be triggered when the SLA event happens aren't.
If you change the issue that does not affect the SLA start/pause/stop AFTER the SLA has started, it will reset the target time for the automation when handler to the full SLA goal time (minus the 60 minutes, as the first event is fired 60 min before breach)
and for issues that drag on and drag on (i.e. lots of updates) it never will.
The following query can be used for find out about SLA's time promise for future
SELECT t."ID", (p.pkey || '-' || i.issuenum) AS issue, t."CLASSIFICATION", t."STATUS", TIMESTAMP WITH TIME ZONE 'epoch' + (t."CREATED_TIME_MILLIS"/1000) * INTERVAL '1 second' AS created_time, TIMESTAMP WITH TIME ZONE 'epoch' + (t."UPDATED_TIME_MILLIS"/1000) * INTERVAL '1 second' AS updated_time, TIMESTAMP WITH TIME ZONE 'epoch' + (t."TARGET_TIME_MILLIS"/1000) * INTERVAL '1 second' AS target_time FROM "AO_F1B27B_KEY_COMPONENT" c LEFT JOIN "AO_F1B27B_PROMISE" t ON t."ID" = c."TIMED_PROMISE_ID" LEFT JOIN jiraissue i ON i.id = c."VALUE"::int LEFT JOIN project p ON p.id = i.project ORDER BY t."ID" ASC;
How to reproduce
- Create any SLA
- Create an issue
- Keep updating that issue and see SLA's time promise "target_time" updated incorrectly
- duplicates
-
-
- Closed
-
- relates to
-
-
- Closed
-
- was cloned as
-
TESLA-544 Failed to load
| Form Name | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
[JSDSERVER-3682] SLA's time promise is not scheduled correctly after updating
Hi,
This currently affects 3.1.7 so would recommend updating.
Regards
Matthew
Angus Law
added a comment - Just to confirm - is this affecting v3.1.7?
Or just 3.2 (unreleased)? This issue was created as a result of my original support request, so I have a bit of ownership on this one.
The description on the ticket is crypically worded, so let me rephrase what is going on here.
- Let's say I have a ticket that is about to breach an SLA
- If that ticket gets updated in ANY WAY (i.e. comment/attribute change), the "promise" event on the SLA Breach gets "incorrectly recalculated" (per the ticket's description)
- So while my SLA's are getting breached, the Automation Rules, which are supposed to trigger do NOT
- The net result is that ANY Automation rule that is supposed to be triggered on an SLA Breach does so Inconsistently and Unreliably
@Atlassian, this is UNACCEPTABLE! #Automation is supposed to improve quality, not erode it.
Please provide an update soon informing us on when this issue will be resolved
@Atlassian this bug is anything but 'Minor' , please revise and provide an ETA soonest
this is resulting in automation events (for example, warnings when about to breach SLA's) not firing on the tickets that need them most urgently
mmcmahon
I am using version 3.2.0-139 but automation stops intermittently. This is very annoying as we have some very critical automation. A restart cannot be performed just to restart the automation
I see the below error