A simultaneous update to a Task from different threads can result in incorrect processing of the Task SLAs. One update gets the changes to the record committed to the database first but then takes some time to process the business rules. The second update makes changes to the same record but the business rules process faster, then runs the TaskSLAController and gets the mutex for processing the Task's SLAs. The first update has to wait for the Task's SLA mutex to become available. Once it is available, the TaskSLAController runs again for the second update but it uses the "current" object, which now contains stale data because the second simultaneous update has changed the data in the record.

Steps to Reproduce


  1. Open two browsers.

  2. Log in to your instance using one of your browsers.

  3. Create the following business rule:

    Name: PRB623398
    Table: Incident
    Order: 10
    When: after
    Update: ticked
    Condition: Short description is delayed
    Script: gs.sleep(10000);

  4. Create a new incident that causes a Task SLA to attach.
    For example, in the base system instance, change the impact and urgency fields to 2 which sets priority fields set to 2.

  5. Save the record.

  6. Confirm that the Task SLA has been attached to the task.

  7. In the second browser, connect to the same instance.

  8. Open the form for the Incident that you just created.

  9. In the first browser, open the incident and make changes to the fields that will cause the Task SLA to pause.

    For example, in a base system instance, change the State field to Awaiting User Info as this is the pause condition for the Priority 2 SLA) and also change the Short Description to just the word delayed. When saving, this triggers the business rule created in step 3 above, which will introduce a 10-second delay during the processing of the after business rules. Do NOT save these changes yet.

  10. In the second browser, make changes to the Incidents fields that will stop the Task SLA.

    For example, in a base system instance, change the incident State field to Resolved, populate the mandatory Close code and Close notes fields, and change theShort Description to contain the text no delay. Do NOT save these changes yet.

  11. In your first browser, where the Short Description is showing delayed, save the incident and then quickly (within 10 seconds) go to the second browser window and click Save.

    The second browser update should finish before the first browser.

    Reloading the Incident form in either browser shows the updates you made to the Incident in the second browser. However, the attached Task SLA record reflects the changes made in the first browser which is effectively the previous update to the Incident. On a base system instance, and based on the steps above, the Incident would be Resolved. This is the stop condition for the Priority 2 SLA Definition, but the Task SLAs will show 1 completed Priority 2 Task SLA and also a second Priority 2 one with a state of Paused.


This issue is under review. If you are able to upgrade, review the Fixed In field below to determine the versions that have a permanent fix. To receive notifications when more information is available, subscribe to this Known Error article by clicking the Subscribe button at the top right of the article.

Related Problem: PRB623398

Seen In

Calgary Patch 2 Hot Fix 5
Eureka Patch 7 Hot Fix 8

Fixed In

Fuji Patch 2

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2017-07-21 09:48:32